Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nobody Understands REST or HTTP

blog.steveklabnik.com

Post reply on HN
Print view View original

51–60 of 72 posts

Re: Nobody Understands REST or HTTP

#51

Post by richardlblair »

There are numerous opinions on the subject of RESTful apis. The author of this post makes many good points, but I, like many of you disagree with his opinion on versioning.

While putting the version into the header is clever, it reduces the usability of your api. When you are designing a RESTful api you typically want to design your api so that it is simple and easy to implement. Nothing is easier than being able to explore an api via a web browser. If you make the user specify versions in the header than they will have to install a browser plugin to explore your api.

You have to consider that you aren't always "selling" to other developers who understand http headers. You could be "selling" to non technical project managers and CEOs who simply don't understand http headers. They do understand URIs, though. So if you can provide these people with a URI that just works, and they can poke around and see data they have a greater chance of understanding and getting excited about your API.

Re: Nobody Understands REST or HTTP

#52

Post by javascriptlol »

telent wrote: post #50
javascriptlol wrote: post #40

Earlier quoted context omitted.

What? How can you say REST is going to give you a bunch of stuff "for free" when you haven't even seen the application. How do you know you're even going to get what you want? This is the central conceit here.

How can you say (TCP|Unix|C) is going to give you a bunch of stuff "for free" when you haven't even seen the application. How do you know you're even going to get what you want? You don't, of course, but it's usually a pretty reasonable assumption that the effort involved in implementing your own (reliable stream sockets|scheduler and memory manager|high level language compiler) will eclipse severalfold any advantage…

>You don't, of course, but it's usually a pretty reasonable assumption that the effort involved in implementing your own (reliable stream sockets|scheduler and memory manager|high level language compiler) will eclipse severalfold any advantage from doing so.

Wrong. I implement network protocols for a living, and I use often use UDP because TCP is not sufficient for the purpose. So yeah, this is the problem: your conceit that your upfront design is going to be "enough" for everything.

Re: Nobody Understands REST or HTTP

#53

Post by richardlblair »

tzaman wrote: post #9

Interesting. But it has one flaw; how exactly would I do this curl https://api.twilio.com/2010-04-01/Accounts -H "Accept: application/json inside a browser on a normal GET request?

One way I have solved this issue is to look for the Accept header. If no valid formatting options are available in the Accept header look for a query string parameter.

To me this is vital. Being able to explore an api within an browser makes it exponentially easier to understand and use.

Re: Nobody Understands REST or HTTP

#54

Post by richardlblair »

almost wrote: post #23
nirvdrum wrote: post #22

Earlier quoted context omitted.

Huh? 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…

But 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 u…

How 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.

Re: Nobody Understands REST or HTTP

#55

Post by javascriptlol »

telent wrote: post #50
javascriptlol wrote: post #40

Earlier quoted context omitted.

What? How can you say REST is going to give you a bunch of stuff "for free" when you haven't even seen the application. How do you know you're even going to get what you want? This is the central conceit here.

How can you say (TCP|Unix|C) is going to give you a bunch of stuff "for free" when you haven't even seen the application. How do you know you're even going to get what you want? You don't, of course, but it's usually a pretty reasonable assumption that the effort involved in implementing your own (reliable stream sockets|scheduler and memory manager|high level language compiler) will eclipse severalfold any advantage…

And btw, the point I am making is not against high level constructs. Once you have sockets you can build whatever you like. The problem is HTTP is the bottom level of the web. If you had proper facilities at the bottom you could have your HTTP as a library and I can have my real-time protocols. The web constrains engineers based on some academic's rationalistic ideas about optimisation.

Re: Nobody Understands REST or HTTP

#56

Post by richardlblair »

almost wrote: post #23
nirvdrum wrote: post #22

Earlier quoted context omitted.

Huh? 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…

But 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 u…

You also have to consider which of these 2 are easier to understand:

api.example.com/v2/account

or api.example.com/account Accept: application/vnd.steveklabnik-v2+json

And I'm not talking about how easy it is for Developers to understand. I'm talking about how easy it is for Everybody to understand.

Re: Nobody Understands REST or HTTP

#57

Post by telent »

javascriptlol wrote: post #52
telent wrote: post #50

Earlier quoted context omitted.

How can you say (TCP|Unix|C) is going to give you a bunch of stuff "for free" when you haven't even seen the application. How do you know you're even going to get what you want? You don't, of course, but it's usually a pretty reasonable assumption that the effort involved in implementing your own (reliable stream sockets|scheduler and memory manager|high level language compiler) will eclipse severalfold any advantage…

>You don't, of course, but it's usually a pretty reasonable assumption that the effort involved in implementing your own (reliable stream sockets|scheduler and memory manager|high level language compiler) will eclipse severalfold any advantage from doing so. Wrong. I implement network protocols for a living, and I use often use UDP because TCP is not sufficient for the purpose. So yeah, this is the problem: your conc…

See where I said "usually"? And where I said your experience is valid but don't assume it's universal? Right

Re: Nobody Understands REST or HTTP

#58

Post by javascriptlol »

telent wrote: post #57
javascriptlol wrote: post #52

Earlier quoted context omitted.

>You don't, of course, but it's usually a pretty reasonable assumption that the effort involved in implementing your own (reliable stream sockets|scheduler and memory manager|high level language compiler) will eclipse severalfold any advantage from doing so. Wrong. I implement network protocols for a living, and I use often use UDP because TCP is not sufficient for the purpose. So yeah, this is the problem: your conc…

See where I said "usually"? And where I said your experience is valid but don't assume it's universal? Right

I never said my experience was universal, nor did I imply it. So what's your point?

Re: Nobody Understands REST or HTTP

#59

Post by javascriptlol »

telent wrote: post #57
javascriptlol wrote: post #52

Earlier quoted context omitted.

>You don't, of course, but it's usually a pretty reasonable assumption that the effort involved in implementing your own (reliable stream sockets|scheduler and memory manager|high level language compiler) will eclipse severalfold any advantage from doing so. Wrong. I implement network protocols for a living, and I use often use UDP because TCP is not sufficient for the purpose. So yeah, this is the problem: your conc…

See where I said "usually"? And where I said your experience is valid but don't assume it's universal? Right

The fact that you think it us "usually" a valid assumption is exactly the conceit I am talking about. It's only "usually" assumed to be true because the people who have different requirements don't come to the web because it's such a limp platform.

Re: Nobody Understands REST or HTTP

#60

Post by drawkbox »

thomasbachem wrote: post #14

Thanks so much for saying what needed to be said :)! David Zülke has a very good talk about REST that he's holding at conferences around the world regularly: http://www.slideshare.net/Wombert/designing-http-interfaces-... .

Ah yes the conferences... When will the RMM (REST Maturity Model) certification, books and classes be available? It will be the CMMI + SWEBOK conferences all over again gangbusters! j/k. All good stuff it is just a good portion of it is to sell books/conferences and sometimes the good engineering parts are lost on the idea that in the end engineering is making things more simple not more complex.

It is a good presentation and hits on many good points but also makes the REST model a little too narrow for most client/consumer usage today easily.

Post reply on HN