Common REST Mistakes • Hacker News Board

Re: Common REST Mistakes

#11

Post by derefr » Sat, Feb 13, 2010, 2:03 AM UTC

idlewords wrote: post #6

Several of these points are highly prescriptive without offering any motivation for the advice. For example, "your public API should not depend on the structure of your URIs. Instead there would typically be a single XML file that points to the components of your service." It's difficult to understand this kind of point without an example in hand - preferably an example taken from an actual website. The whole list pr…

By "sessions are irrelevant", he basically means "don't recreate circuit switching on top of your packet-switched TCP/IP connection." Each HTTP request should carry with it all the state required to do what it needs to do (including state stored in cookies et all); it shouldn't be dependant on what has come before or what will come after it.

Re: Common REST Mistakes

#12

Post by derefr » Sat, Feb 13, 2010, 2:10 AM UTC

tlack wrote: post #9

idlewords wrote: post #6

Several of these points are highly prescriptive without offering any motivation for the advice. For example, "your public API should not depend on the structure of your URIs. Instead there would typically be a single XML file that points to the components of your service." It's difficult to understand this kind of point without an example in hand - preferably an example taken from an actual website. The whole list pr…

I agree. A lot of the more pedantic REST advocates seem to use this kind of thinking, such as implying that we shouldn't use descriptive URIs because the client or programmer shouldn't need to understand how the URIs are structured. If that's the case, surely we could break REST convention as much as we want and just make the programmer or client go along with it. I think when most normal people say REST, they simply…

I don't think it was implied that we shouldn't use descriptive URIs—just that descriptive URIs should be treated in roughly the way we treat comments—they're for humans to work with, not computers, unless there is an established microformat (like the various -Doc formats used in comments) that the service can be guaranteed to obey. That microformat would, obviously, be linked to in place of the index XML file—as it would be able to be used to procedurally generate same.

Re: Common REST Mistakes

#13

Post by derefr » Sat, Feb 13, 2010, 2:13 AM UTC

telemachos wrote: post #10

Since a number of people have mentioned point #6 (Sessions are irrelevant), I have a question: Can anyone point to a concrete, more detailed discussion of how to do authentication and authorization in a RESTful manner? I may be missing something very obvious, but I just don't see how this should/can/might look. (Just to be explicit, I'm not trolling. I'm confused.)

Basically, http://en.wikipedia.org/wiki/Digest_access_authentication#Ex... but with anything you like in place of the GET.

Re: Common REST Mistakes

#14

Post by ratsbane » Sat, Feb 13, 2010, 2:24 AM UTC

tlack wrote: post #9

idlewords wrote: post #6

Several of these points are highly prescriptive without offering any motivation for the advice. For example, "your public API should not depend on the structure of your URIs. Instead there would typically be a single XML file that points to the components of your service." It's difficult to understand this kind of point without an example in hand - preferably an example taken from an actual website. The whole list pr…

I agree. A lot of the more pedantic REST advocates seem to use this kind of thinking, such as implying that we shouldn't use descriptive URIs because the client or programmer shouldn't need to understand how the URIs are structured. If that's the case, surely we could break REST convention as much as we want and just make the programmer or client go along with it. I think when most normal people say REST, they simply…

I agree too. Roy Fielding's dissertation on REST does say that URIs should not contain information about the identity of the user nor the details of the implementation of the resource on the server (no .php, .cgi, .aspx) but in a section on URIs (6.2.1) he does say "...REST accomplishes this by defining a resource to be the semantics of what the author intends to identify..." I read that as a requirement for descriptive URLs.

And I think of Fielding's dissertation, together with a few RFCs like 2616, as the founding documents of REST.

Re: Common REST Mistakes

#15

Post by kmt » Sat, Feb 13, 2010, 2:39 AM UTC

derefr wrote: post #13

telemachos wrote: post #10

Since a number of people have mentioned point #6 (Sessions are irrelevant), I have a question: Can anyone point to a concrete, more detailed discussion of how to do authentication and authorization in a RESTful manner? I may be missing something very obvious, but I just don't see how this should/can/might look. (Just to be explicit, I'm not trolling. I'm confused.)

Basically, http://en.wikipedia.org/wiki/Digest_access_authentication#Ex... but with anything you like in place of the GET.

Is the well known and used cookie based authentication in conflict with REST? In my mind it's not, it's orthogonal to it.

If not logged in, redirect to a login page (resource) which upon success redirects back, e.g. GET login?next=desired_resource.

If logged in but not authorized to perform the action on the resource return 401.

That's it basically, isn't it? Also not trolling, challenge me if I'm missing something please.

Re: Common REST Mistakes

#16

Post by wanderr » Sat, Feb 13, 2010, 3:31 AM UTC

REST has always felt a little bit dirty to me; an improper commingling of what should be two different layers. To me, using aspects of the HTTP protocol to have meaning for a higher level service is a bit like using aspects of the TCP protocol as part of the HTTP definition, where in a more ideal setup they should be independent, but layered on top of one another. Almost all of the REST mistakes mentioned in this article are due to the unholy matrimony of the two layers, and the misunderstandings and abuses that arise from that. Additionally, using HTTP error codes can break compatibility for anything running in a browser plugin (i.e. Flash) because the browser eats the error code and does not pass it on to the plugin. Needless to say, I'm a big fan of RPC which runs over HTTP POST normally but isn't married to the underlying protocol. I think SOAP gives RPC a bad name (I certainly hate the crap out of it) and doesn't properly separate the protocols either, using HTTP codes to indicate errors and such.

Re: Common REST Mistakes

#17

Post by phaedrus » Sat, Feb 13, 2010, 3:52 AM UTC

I'm actually designing a REST system to connect together the subsystems of a robot with a number of independent microcontrollers, so this is very relevant. Keep the REST articles coming, please!

Re: Common REST Mistakes

#18

Post by johns » Sat, Feb 13, 2010, 4:20 AM UTC

scdlbx wrote: post #2

What REST actually is, is not explained on this page. More information can be found here: http://en.wikipedia.org/wiki/Representational_State_Transfer

Better explanation: http://tomayko.com/writings/rest-to-my-wife

Re: Common REST Mistakes

#19

Post by steveklabnik » Sat, Feb 13, 2010, 4:55 AM UTC

telemachos wrote: post #10

Since a number of people have mentioned point #6 (Sessions are irrelevant), I have a question: Can anyone point to a concrete, more detailed discussion of how to do authentication and authorization in a RESTful manner? I may be missing something very obvious, but I just don't see how this should/can/might look. (Just to be explicit, I'm not trolling. I'm confused.)

If you know Ruby, you could check out AuthLogic.

Re: Common REST Mistakes

#20

Post by kmt » Sat, Feb 13, 2010, 6:15 AM UTC

wanderr wrote: post #16

REST has always felt a little bit dirty to me; an improper commingling of what should be two different layers. To me, using aspects of the HTTP protocol to have meaning for a higher level service is a bit like using aspects of the TCP protocol as part of the HTTP definition, where in a more ideal setup they should be independent, but layered on top of one another. Almost all of the REST mistakes mentioned in this art…

I think you might be wrong about the 'underlying protocol'. HTTP is an application layer protocol. If something feels dirty it is to put another protocol on top of it especially if it doesn't add value.

With REST, you are not adding more special meaning than the HTTP methods. Using those methods according to the spec is all there is to it. If that's enough to do your business, why add more to it? Things should be simple as much as possible.