feat(api-idorslug): Rename Path paramaters to project_id_or_slug
#69716
Conversation
github-actions
bot
added
Scope: Frontend
|
🚨 Warning: This pull request contains Frontend and Backend changes! It's discouraged to make changes to Sentry's Frontend and Backend in a single pull request. The Frontend and Backend are not atomically deployed. If the changes are interdependent of each other, they must be separated into two pull requests and be made forward or backwards compatible, such that the Backend or Frontend can be safely deployed independently. Have questions? Please ask in the |
|
i think its complaining about frontend changes b/c i updated api-docs |
| @@ -198,9 +198,9 @@ | |||
| } | |||
| }, | |||
| { | |||
| "name": "project_slug", | |||
| "name": "projproject_id_or_slugct_slug", | |||
| @@ -155,7 +155,7 @@ Retrieve a collection of feedback items. | |||
| } | |||
| ``` | |||
|
|
|||
| ## Feedback [/projects/<organization_slug>/<project_slug>/feedback/<feedback_id>/] | |||
| ## Feedback [/projects/<organization_slug>/<project_id_or_slug>/feedback/<feedback_id>/] | |||
|
@nhsiehgit just to clarify Raj has rolled out the feature flag already little by little and they've been soaking in GA for a while. His current change is just renaming the variable the way it shows up in the docs. Do you think it makes sense to roll that out eventually? 🤔 I don't think it makes sense and it makes his work harder because he has to maintain two variable for docs purposes. |
|
hmm |
|
I might be missing some key information here. But for the sake of people who don't know the reasoning:
|
|
@anonrig you will find most of those questions answered here: https://www.notion.so/sentry/Make-APIs-work-with-Slug-ID-cbaf68b883b843d499191e9cc4c116d3 The page is not fully capturing this and for the sake of public readers: slug renames need to be communicated through the Hybrid Cloud RPC system and are a pain. We also persist slugs in the org level auth tokens. As a result an org slug rename currently breaks uploads and it requires synching through the hybrid cloud bridge. We have decided a while back that it would be beneficial to support IDs in all cases so that we have a stable identifier in most communications that is unaffected by slug renames. |
|
Our common objects are heavily queried by id already and indexed on id. The convert_arg changes that are happening now are basically getting the ID from API and turn it to slug so most backend except this one part would not change at all. |
Bundle ReportChanges will increase total bundle size by 1.4kB ⬆️
|
iamrajjoshi
deleted the
raj/api-idorslug/rename-path-params/project_slug
branch
I am working on making our APIs work with slug and id in our path parameters. Over the path month, we have updated the endpoints so they can support both parameters. As a final step, we are renaming the parameters from
{resource}.slugto{resource}.id_or_slug.There will be a similar PR for
organization_slug