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

11–20 of 72 posts

Re: Nobody Understands REST or HTTP

#11

Post by rue »

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?

The short answer is that browser vendors need to get their act together. They've shirked this because no-one's demanded it.

Fortunately until they do, broadly, a browser user will always want the newest resource, and the type can usually be defaulted (you're using a browser, so you want HTML by default where available). Additionally, XHR and related technologies usually allow adding custom headers.

Re: Nobody Understands REST or HTTP

#13

Post by thomasbachem »

StavrosK wrote: post #2

This says versioning in the URI is wrong. Why? I much prefer separating my API versions into different files at the dispatcher level. Doing it with the header would be a mess in most frameworks, and I don't see what it hurts. Also, what about custom HTTP verbs? Many times I need something more than GET/PUT/POST/DELETE. What happens then? I haven't seen anyone talk about that.

You're using the wrong frameworks :)

Re: Nobody Understands REST or HTTP

#15

Post by latch »

He didn't go over the common example of paging by including

   nav { prev: '...', next: '....'}
in the response. But, the thing that always concerns me about this is that it requires the client to maintain state. If you consume such a web service in a web app, and the user hits "next", you'll have to have stored the next url somewhere.

Re: Nobody Understands REST or HTTP

#18

Post by icebraining »

latch wrote: post #15

He didn't go over the common example of paging by including nav { prev: '...', next: '....'} in the response. But, the thing that always concerns me about this is that it requires the client to maintain state. If you consume such a web service in a web app, and the user hits "next", you'll have to have stored the next url somewhere.

If you want to show any content to the user, you'll always need to hold it in memory somewhere; that's inevitable. Storing an URL for an action is just part of the rest.

Personally, I'd just use a closure and bind it immediately to the event handler of the UI element.

Re: Nobody Understands REST or HTTP

#19

Post by StavrosK »

almost wrote: post #6
StavrosK wrote: post #2

This says versioning in the URI is wrong. Why? I much prefer separating my API versions into different files at the dispatcher level. Doing it with the header would be a mess in most frameworks, and I don't see what it hurts. Also, what about custom HTTP verbs? Many times I need something more than GET/PUT/POST/DELETE. What happens then? I haven't seen anyone talk about that.

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…

You 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!

Re: Nobody Understands REST or HTTP

#20

Post by Argorak »

latch wrote: post #15

He didn't go over the common example of paging by including nav { prev: '...', next: '....'} in the response. But, the thing that always concerns me about this is that it requires the client to maintain state. If you consume such a web service in a web app, and the user hits "next", you'll have to have stored the next url somewhere.

Isn't the whole point of REST/Hypermedia that the client holds the state instead of the server?
Post reply on HN