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

31–40 of 72 posts

Re: Nobody Understands REST or HTTP

#31

Post by drawkbox »

jedberg wrote: post #30
almost wrote: post #6

Earlier quoted context omitted.

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…

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

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

Re: Nobody Understands REST or HTTP

#33

Post by digitaltoad »

brown9-2 wrote: post #29
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.

It sounds like you are making an API design choice based on how easy it is for you to implement something internally. What about your client's ease? Version in the URL requires them to update the URLs everywhere. Version in the accept header is likely a one line change somewhere.

This is not necessarily true. A client could easily have the api version segment of the url in a central configuration location.

Re: Nobody Understands REST or HTTP

#35

Post by davedx »

drawkbox wrote: post #31
jedberg wrote: post #30

Earlier quoted context omitted.

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

I 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…

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

Re: Nobody Understands REST or HTTP

#36

Post by javascriptlol »

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.

The problem is designing all this nonsense into the bottom layer in the first place. I've never heard a good argument as to why any of this is better than just starting with raw sockets for an app talking to a server.

Take HATEOAS for example; a completely academic waste of time. Writing a tiny bit of API documentation isn't hard. Caching is an awful thing to be designing in without knowing the specific application. Verbs are a hack bolted on to make hideous form/link driven applications work when the user reloads or moves back/forward.

Re: Nobody Understands REST or HTTP

#37

Post by javascriptlol »

If I want to raise my blood pressure into the 180's all I have to do is open a thread about web design "principles".

He has the perfect anti-example for HATEOAS right in there: financial transactions. You would never in 1 million years want to discover the API for such a thing by experimentation, because there are specific precision requirements.

Every time someone tries to explain the benefits of this nonsense to me it's either 1) something you could already do with sockets 20+ years ago, or 2) a poorly motivated academic idea that doesn't get me closer to implementing a correct system with good documentation.

Re: Nobody Understands REST or HTTP

#38

Post by javascriptlol »

javascriptlol wrote: post #36
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.

The problem is designing all this nonsense into the bottom layer in the first place. I've never heard a good argument as to why any of this is better than just starting with raw sockets for an app talking to a server. Take HATEOAS for example; a completely academic waste of time. Writing a tiny bit of API documentation isn't hard. Caching is an awful thing to be designing in without knowing the specific application.…

Don't downvote, comment. Or admit to yourself that you can't respond to my criticism.

Re: Nobody Understands REST or HTTP

#39

Post by psadauskas »

javascriptlol wrote: post #36
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.

The problem is designing all this nonsense into the bottom layer in the first place. I've never heard a good argument as to why any of this is better than just starting with raw sockets for an app talking to a server. Take HATEOAS for example; a completely academic waste of time. Writing a tiny bit of API documentation isn't hard. Caching is an awful thing to be designing in without knowing the specific application.…

Except that when you follow all of REST, including HATEOAS, that part of the API documentation is FREE. And the caching is FREE, because its already been designed for you. Which is the whole point.

Re: Nobody Understands REST or HTTP

#40

Post by javascriptlol »

psadauskas wrote: post #39
javascriptlol wrote: post #36

Earlier quoted context omitted.

The problem is designing all this nonsense into the bottom layer in the first place. I've never heard a good argument as to why any of this is better than just starting with raw sockets for an app talking to a server. Take HATEOAS for example; a completely academic waste of time. Writing a tiny bit of API documentation isn't hard. Caching is an awful thing to be designing in without knowing the specific application.…

Except that when you follow all of REST, including HATEOAS, that part of the API documentation is FREE. And the caching is FREE, because its already been designed for you. Which is the whole point.

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.
Post reply on HN