7 ms·
With a RESTful API you don't tend to need IDs most of the time, you just use URLs. So having all the versioning info in the URL is not so great, you change the
by almost 15y ago
With a RESTful API you don't tend to need IDs most of the time, you just use URLs. So having all the versioning info in the URL is not so great, you change the version and suddenly all the URLs aren't valid anymore.
But more important that is upgrading a version on an API may not be an all or nothing thing. You might want to start using the new features of the API on one resource type but you aren't ready to upgrade your usage on everything else. If the version is in the API you'll have to take apart and put back together urls to get the right ones, this is logic you don't want to have to encode into your client. If on the other hand you use Accept headers to do versioning you can have as fine grained control as you need.
Regarding the custom HTTP verbs it may seem like you need those at first but in practice you really don't and there is almost always a good clean way of doing things that doesn't break anything (or so I've found). I find that the solution is usually to introduce another resource or two, the transactions example from the article is a perfect example of this.
I know it sometimes seems like this is all abstract stuff that has no impact on the real world but it does make sense eventually! It's really lovely to use a properly RESTful API :)
- nirvdrum 15y agoHuh? The whole point of having a version in the URL is so you can roll out a new set of URLs and their corresponding endpoints without touching the old ones. When v2 of the API comes out, you still support v1. That's no different than using headers. If you sunset or change an API call, the header isn't going to save you any trouble. In fact, since the client now won't get a 404, but rather something else, the cost of debugging goes up pretty substantially.
- almost 15y agoBut how do you deal with the partial upgrade scenario? I might want to use a few of the new features in my client code but not have the time to upgrade (and test!) everything just yet. Of course version numbers in URLs can have their place too. But I think they should only really be used in situations where you have upgraded so much that the original URL space just makes no sense. And if you can avoid huge breaking upgrades like that through good initial design then all the better :)
- nirvdrum 15y agoThe same way you'd handle it on a per-header basis . . . you just use the new API version in the URL where needed. Sorry, I feel like I must be missing something here.
- almost 15y agoYou are a little. In a properly RESTful API you simply don't construct URLs most of the time. Instead you follow links. If you change the URL structure you break the links. If that's what you want then a version number in the URL makes sense, but in a properly RESTful API that's probably not what you want. I think for a lot of people the reason they don't see the benefit of things from REST is they try to use them in isolation. You say "this is useless for my RPC style API!" and you are right.
- nirvdrum 15y agoBut, if you follow a link and that link is generated by the server, I still don't see how encoding a version number in the URL makes things any harder. FWIW, I've made an effort to follow the purity of it, but the APIs I see that try to do true ReST are insanely obtuse. If you know of any real world case studies where a provider went from "fake" ReST to true ReST, I'd love to read it. The contrived examples are not helping me out in the comprehension department.
- richardlblair 15y agoHow frequently do you think restful apis move to a new version? Typically you don't release a new version until you need to do significant changes to the entire layout of your api. In which case the old version is not even relevant. With this in mind, you would not want to promote using a new version of the api for one resource with an old version of the api for another resource. Just thinking about it sounds dirty. Your migration strategy should include sufficient time for you to assist your clients to move to your newer versions.
- almost 15y ago
- Vitaly 15y agoyou are somewhat missing the point. the idea of proper REST is that you NEVER should generate your urls. you take them from the resources. now suppose you have an application that consumes RESTful API. if you do it "wrong" you probably store record ids in your local db and then access stuff from the API by constructing your own urls. a more proper way of doing it is to store the compete resource urls and not just ids. but in this case you have a version update problem. When you release a new version of the app that supports new version of the API you will now need to go over all the stored resource urls and update the version, probably doing some regexing etc. with version in the headers you can store full resource urls and not have to change them every time api version changes.
- StavrosK 15y agoYou have swayed me, old man. My next API will use headers for versioning, thank you. As far as the custom verbs are concerned, you might be right, I'll need to think about it when I next need to design an API. Thanks again!
- jedberg 15y agoIf I want to share a link to your API, and you're using accept headers for versioning, how do share that URL? I think that not only is using accept headers worse, I think it is flat out wrong. That's not what the accept header is for. It's for client specific things only. The version of the API you need is NOT client specific.
- drawkbox 15y agoI agree, lots of the Header only people live in a Utopian view of services. Many times these services are needed at the javascript, even plugin (flash, unity, etc) level that don't work well with hidden headers since all they have is a url and a body to make it work. The Academic view of REST is ideal but usage in the real world is difficulty with headers only. A situation that may arise is people not even aware they are using the wrong version of the api. And which one do you default to? Do you start with the version header always or do you add it into the system on version 2? Then do you require the version header? What happens if you didn't add that in version 1? Which one do you default to the new one? Is it really easier to change one line header than one line service prefix? It is much much easier when maintaining a large service with more uri focused api routes/actions/verbs at times. It still is defined as rest but has some rpc elements to it. You don't even have to go down to the the model like /api/profile/[uuid]. You can do things like /api/signup /api/login and match those sensible abstractions into the rest api that lives above the model layer. This is always more flexible for minimizing versions and allowing core model changes without having to change much and provides a better consumer experience of the api. This is more of a REST and RPC mix that works well if you have to work with things beyond just backend services such as games, interactives, scripted experiences etc. I make services fully RESTful when I can but I have to build services that run in scripted clients without easy access to headers, this is where header based versioning is more difficult for the consumer of the service. What I have been doing is looking first for a header, then for the url version, the routes are abstractions anyways so I route those accordingly. I am liberal in what I accept, conservative in what I send like a good service should be.
- davedx 15y agoCan you elaborate on Unity not working well with headers? I've just started doing some web-stuff with it and found that so far it's been okay.