From 9f9eafe0a10e398bea175bc947449e5515a887cb Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" <41898282+github-actions[bot]@users.noreply.github.com> Date: Fri, 24 Jul 2026 10:03:11 +0200 Subject: [PATCH] chore: sync content to repo (#10174) Co-authored-by: nilbuild <4921183+nilbuild@users.noreply.github.com> --- .../filtering-sorting--search@dL3YellfAszBeJnm8KEYE.md | 2 +- .../content/naming-conventions@0yY_lWzWVOC_WmPoyHw8W.md | 2 +- .../api-design/content/oidc@jWekRGRa1131w92oS1HeW.md | 5 +++-- 3 files changed, 5 insertions(+), 4 deletions(-) diff --git a/src/data/roadmaps/api-design/content/filtering-sorting--search@dL3YellfAszBeJnm8KEYE.md b/src/data/roadmaps/api-design/content/filtering-sorting--search@dL3YellfAszBeJnm8KEYE.md index 17ac2a7a2..b7c0843a0 100644 --- a/src/data/roadmaps/api-design/content/filtering-sorting--search@dL3YellfAszBeJnm8KEYE.md +++ b/src/data/roadmaps/api-design/content/filtering-sorting--search@dL3YellfAszBeJnm8KEYE.md @@ -1,6 +1,6 @@ # Filtering, Sorting & Search -Filtering, sorting, and search are query capabilities that let API consumers retrieve exactly the data they need rather than fetching everything and processing it client-side. Filtering narrows results by field values (?status=active), sorting orders them (?sort=created_at&order=desc), and search allows freetext or fuzzy matching across fields. Designing these using predictable query parameter names and clearly documenting supported combinations is a significant part of API usability. +Filtering, sorting, and search are query capabilities that let API consumers retrieve exactly the data they need rather than fetching everything and processing it client-side. Filtering narrows results by field values (?status=active), sorting orders them (?sort=created\_at&order=desc), and search allows freetext or fuzzy matching across fields. Designing these using predictable query parameter names and clearly documenting supported combinations is a significant part of API usability. Visit the following resources to learn more: diff --git a/src/data/roadmaps/api-design/content/naming-conventions@0yY_lWzWVOC_WmPoyHw8W.md b/src/data/roadmaps/api-design/content/naming-conventions@0yY_lWzWVOC_WmPoyHw8W.md index e4a20c509..7cb3d7b34 100644 --- a/src/data/roadmaps/api-design/content/naming-conventions@0yY_lWzWVOC_WmPoyHw8W.md +++ b/src/data/roadmaps/api-design/content/naming-conventions@0yY_lWzWVOC_WmPoyHw8W.md @@ -1,6 +1,6 @@ # Naming Conventions -Naming conventions are the rules you follow to keep your API's URLs, parameters, and field names consistent and predictable. This includes decisions like using plural nouns for collections (/users not /user), lowercase kebab-case for URLs, camelCase or snake_case for JSON fields, and avoiding verbs in resource paths. Consistent naming reduces friction for developers consuming your API and signals that the API was designed deliberately rather than assembled ad hoc. +Naming conventions are the rules you follow to keep your API's URLs, parameters, and field names consistent and predictable. This includes decisions like using plural nouns for collections (/users not /user), lowercase kebab-case for URLs, camelCase or snake\_case for JSON fields, and avoiding verbs in resource paths. Consistent naming reduces friction for developers consuming your API and signals that the API was designed deliberately rather than assembled ad hoc. Visit the following resources to learn more: diff --git a/src/data/roadmaps/api-design/content/oidc@jWekRGRa1131w92oS1HeW.md b/src/data/roadmaps/api-design/content/oidc@jWekRGRa1131w92oS1HeW.md index 99c84c6d2..737f54741 100644 --- a/src/data/roadmaps/api-design/content/oidc@jWekRGRa1131w92oS1HeW.md +++ b/src/data/roadmaps/api-design/content/oidc@jWekRGRa1131w92oS1HeW.md @@ -1,5 +1,6 @@ -OIDC -OpenID Connect (OIDC) is an identity layer built on top of OAuth 2.0. While OAuth 2.0 handles authorization (what you can do), OIDC handles authentication (who you are). It introduces the concept of an ID token, a signed JWT that contains claims about the authenticated user, such as their name, email, and user ID. OIDC is the standard behind "Sign in with Google / GitHub / Apple" flows and is the correct choice when your API needs to verify a user's identity, not just their permissions. +# undefined + +OIDC OpenID Connect (OIDC) is an identity layer built on top of OAuth 2.0. While OAuth 2.0 handles authorization (what you can do), OIDC handles authentication (who you are). It introduces the concept of an ID token, a signed JWT that contains claims about the authenticated user, such as their name, email, and user ID. OIDC is the standard behind "Sign in with Google / GitHub / Apple" flows and is the correct choice when your API needs to verify a user's identity, not just their permissions. Visit the following resources to learn more: