Software dev at Netflix | DC techie | Conference speaker | egghead Instructor | TC39 Educators Committee | Girls Who Code Facilitator | Board game geek | @laurieontech on twitter
There are various ways to version your APIs. One of the most common is to include a version indication in your endpoint path. Something like api/v1/posts.
Another common mechanism is to include the version in your header request.
Thanks for your reply. Can you please explain . Suppose i have v1/posts in version when should i have to copy v1/posts code in v2/posts and make a new end point for my changes in v1/posts
Software dev at Netflix | DC techie | Conference speaker | egghead Instructor | TC39 Educators Committee | Girls Who Code Facilitator | Board game geek | @laurieontech on twitter
That depends, which is a frustrating answer I know. Who is reliant on your API? How are you documenting and communicating changes in behavior to the API consumers? Asking the right questions is the first step.
Thanks for your response. i'll try my best to explain the problem. actually we are developing a website something like a food social network. mobile version of this website use api from web server . we changed some features in api and also updated the mobile app for them. Now the users of old mobile app version have issues with new api because they did not updated their app to newer version.for this problem solution we copy the old code in a new route and add a version number something like v2/posts. in this way the old v1/posts also work. i want to ask is this the correct way to do so ? or we have to do something else instead of coping code.
Software dev at Netflix | DC techie | Conference speaker | egghead Instructor | TC39 Educators Committee | Girls Who Code Facilitator | Board game geek | @laurieontech on twitter
Thatβs a potential solution. However, if itβs a matter of a single application talking to a single API it may make more sense to force everyone to update the mobile app. That gets into complicated maintenance and operations consideration.
If it is a public facing API than v1, v2
If it is a private facing API that likely is not to change you can skip versioning.
I have seen versioning with dates.
With GraphQL you don't require versioning in such regard which is the main selling point of GraphQL since versioning can come into play in iOS and Andriod development.
Some pass the version in the header request as Laurie suggests and others pass it in the JSON response.
Some people follow this standard which I bet has an opinion on versioning found somewhere within their website jsonapi.org/
Use versioning as v1, v2, etc. The main reason behind versioning your API's is that once a client starts using your API's you should not make any functional changes to that until unless that client needs it. It's always better to segregate the functionalities by versioning.
Top comments (10)
There are various ways to version your APIs. One of the most common is to include a version indication in your endpoint path. Something like
api/v1/posts
.Another common mechanism is to include the version in your header request.
This site has more details.
Thanks for your reply. Can you please explain . Suppose i have v1/posts in version when should i have to copy v1/posts code in v2/posts and make a new end point for my changes in v1/posts
That depends, which is a frustrating answer I know. Who is reliant on your API? How are you documenting and communicating changes in behavior to the API consumers? Asking the right questions is the first step.
Thanks for your response. i'll try my best to explain the problem. actually we are developing a website something like a food social network. mobile version of this website use api from web server . we changed some features in api and also updated the mobile app for them. Now the users of old mobile app version have issues with new api because they did not updated their app to newer version.for this problem solution we copy the old code in a new route and add a version number something like v2/posts. in this way the old v1/posts also work. i want to ask is this the correct way to do so ? or we have to do something else instead of coping code.
Thatβs a potential solution. However, if itβs a matter of a single application talking to a single API it may make more sense to force everyone to update the mobile app. That gets into complicated maintenance and operations consideration.
If it is a public facing API than
v1
,v2
If it is a private facing API that likely is not to change you can skip versioning.
I have seen versioning with dates.
With GraphQL you don't require versioning in such regard which is the main selling point of GraphQL since versioning can come into play in iOS and Andriod development.
Some pass the version in the header request as Laurie suggests and others pass it in the JSON response.
Some people follow this standard which I bet has an opinion on versioning found somewhere within their website jsonapi.org/
Thank you so much forπ
Use versioning as v1, v2, etc. The main reason behind versioning your API's is that once a client starts using your API's you should not make any functional changes to that until unless that client needs it. It's always better to segregate the functionalities by versioning.
Never use versioning, loosely. I was going to explain why in a fairly long comment, but I changed it into a post instead:
dev.to/dwd/versioning-in-apis-22bj
Hope that helps.
already checked it. Thanks a lot for explanation