3 ms·
I've never really cared for API versioning, especially the "/v1/" or whatever in the URL. Come up with a decent API design from the beginning; commit to backwa
by pbreit 13y ago
I've never really cared for API versioning, especially the "/v1/" or whatever in the URL.
Come up with a decent API design from the beginning; commit to backwards compatibility, non-breaking changes, thorough testing and fast fixes; and stick with it for a decade or so.
- unabridged 13y agoThrowing out backwards compatibility should be an absolute last resort, you may as well start a new project that is written clean from the beginning. No function should be promoted to the core API without serious consideration. Instead use something like /alpha/function-v2.2/ for testing functions that may disappear or be updated, making it easy for clients to write workarounds for these non permanent functions.
- Tohhou 13y agoIt's better to be able to start from a clean slate in the future while still being able to support legacy versions if it is advantageous to do so. You are not smart enough to do it right the first time, because you cannot predict what changing conditions the future will bring.
- joncrocks 13y agoWhich is fine as long as you aren't planning to change your product at all. Yes, you can try and put it off for as long as possible, only making backwards compatible changes. But it's likely at some point you'll need to change something in your API, that simply won't work with existing clients.
- pbreit 13y agoIt's almost always possible to update APIs without breaking backwards-compatibility.