-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Deprecated ID proposal #38
Conversation
Upstream changes
Upstream changes
Upstream changes
demonstrated with cc-zero
If the idea seems sound, I'll reopen the PR on a fresh clone so it doesn't include those merge commits - sorry about that. |
Seems to have more than necessary for mere id changes. Why not just |
That would also work, but the URL for the new one is there so that clients can traverse in a HATEOAS kind of way, rather than expecting a client to know how to construct the relevant URL from an ID. |
Ah, I see. Would what you proposed un-break your client? |
If we updated our client to handle it, yes - we could follow the URLs. TBH, we construct the URLs ourselves anyway, so your proposal would also work, but you know, WWRFD? :) |
Is that an easier update for your client than just updating it to use the new URLs? I'm sorry for breaking it (I did not know there were any actual consumers, though I asked if there were). The idea is the new IDs won't ever need to be changed. But if they were it would seem to me we should just not break clients at all, rather than give them a slightly easier update. |
It's more we have the old IDs in our database that stops it working, though we do have mapping to the new ones. We don't need a fix now, we've handled it, but this is more to propose a mechanism for deprecation in the future. Change always happens ;) |
Is there a best practice for JSON APIs and updating expected field values? |
I don't think there's anything that remains with this PR, I'm closing without merging. We might want to have a previously-known-as-id column in future csv and reflect that in generated json so that a client that wants to future proof against id changes can do so. |
As reported in #37, old IDs should be marked as deprecated, not removed. This is my proposal for how this could be represented, using the old
cc-zero
ID as an example.