Skip to content

Taking APIs Further: Deprecation #34

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

Open
philsturgeon opened this issue Aug 7, 2024 · 0 comments
Open

Taking APIs Further: Deprecation #34

philsturgeon opened this issue Aug 7, 2024 · 0 comments
Assignees

Comments

@philsturgeon
Copy link
Contributor

philsturgeon commented Aug 7, 2024

Surviving Other Peoples APIs covered handling deprecations from the consumer side, but this aims to be a more extensive guide to how API maintainers can handle deprecating entire APIs, endpoints, and potentially even properties by a) updating OpenAPI to cover docs and SDKs, and b) using Sunset and Deprecation headers to alert people via HTTP, then all the softer touch things like emailing people and blogging about it.

https://blog.stoplight.io/deprecating-api-endpoints

https://apisyouwonthate.com/blog/api-evolution-for-rest-http-apis/

https://apisyouwonthate.com/blog/surviving-deprecations-to-resources-and-properties-on-other-apis/

https://blog.treblle.com/best-practices-deprecating-api/

@philsturgeon philsturgeon changed the title Deprecation Part 4: Deprecation Aug 7, 2024
@philsturgeon philsturgeon changed the title Part 4: Deprecation Taking APIs Further: Deprecation Feb 6, 2025
@philsturgeon philsturgeon self-assigned this Feb 27, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant