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

Common REST Mistakes

prescod.net

Post reply on HN
Print view View original

31–40 of 41 posts

Re: Common REST Mistakes

#31

Post by kls »

wanderr wrote: post #27
kmt wrote: post #20

Earlier quoted context omitted.

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

Simplicity is good, but so is flexibility and compatibility. As I mentioned, parts of REST aren't good enough; anything that doesn't have access to http status codes won't be fully compatible. A decent RPC protocol like JSON-RPC is both flexible and simple. An added bonus to not marrying your protocol to http is that your API will work seamlessly over other protocols should the need arise. I have an API that was orig…

I used to argue in favor of json-rpc as well, but I have to say that I have allied with the dark side now. if for no other reason than caching, with REST you have fine control over what addressable resources get cached and which do not. This is huge for performance in some systems. I have found once you use REST semantics in earnest to build an application, it is hard to levy argument against it. So much of the webs infrastructure starts to work with you and not against you once you start to use it.

Re: Common REST Mistakes

#32

Post by kmt »

wanderr wrote: post #27
kmt wrote: post #20

Earlier quoted context omitted.

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

Simplicity is good, but so is flexibility and compatibility. As I mentioned, parts of REST aren't good enough; anything that doesn't have access to http status codes won't be fully compatible. A decent RPC protocol like JSON-RPC is both flexible and simple. An added bonus to not marrying your protocol to http is that your API will work seamlessly over other protocols should the need arise. I have an API that was orig…

I agree with that. But here you aren't talking about HTTP you are talking about RPC. You could have gone with RPC directly from the very beginning. Typically, you put that on top of HTTP to avoid firewalls, etc.

I said simple as possible, but the real world is always complex and one day you may have to use something other than JSON-RPC in which case someone will have to create an adapter or an abstraction. Thankfully this is easy to do in software even if it sometimes looks nightmarish.

Re: Common REST Mistakes

#33

Post by generalk »

blasdel wrote: post #24
sabat wrote: post #21

Earlier quoted context omitted.

I have not read Roy Fielding's dissertation, and so I am speaking out of partial ignorance. But isn't most of this the opposite of what REST is supposed to be? URLs aren't supposed to represent resources? Whahh?

The contents of URL strings are not supposed to represent resources -- If a client of your "REST API" needs to concatenate strings together to form new URLs based on an out-of-band 'specification', YOU'RE DOING IT WRONG Repeat after me: Hypertext. Is. The. Engine. Of. Application. State. URL strings should be completely opaque -- you should be finding link to new resources in other resources, not constructing them yo…

One can build a service that has so-called "Rails-style meaningful URIs" that also returns hyperlinks to new resources. They aren't mutually exclusive.

That said, yes, everyone seems to forget about hypertext. I'm curious: if I'm building a REST-based JSON-formatted service, what's the convention for returning related URIs? Ex: if I return a Product resource andi want to have links to the products image, the owner's resource, edit this product, and so on, is there a standard way to return them in the JSON structure, or doesthis nor matter?

Re: Common REST Mistakes

#34

Post by daredevildave »

kmt wrote: post #15
derefr wrote: post #13

Earlier quoted context omitted.

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

Cookie-based authentication is generally only applicable to the browser interface. From my point of view where REST really shines is at the API level. HTTP authentication while not particularly great in the browser ( mainly because of UI/logging out issues ) is good at the API level where you send your credentials with each request.

Re: Common REST Mistakes

#35

Post by wanderr »

kls wrote: post #31
wanderr wrote: post #27

Earlier quoted context omitted.

Simplicity is good, but so is flexibility and compatibility. As I mentioned, parts of REST aren't good enough; anything that doesn't have access to http status codes won't be fully compatible. A decent RPC protocol like JSON-RPC is both flexible and simple. An added bonus to not marrying your protocol to http is that your API will work seamlessly over other protocols should the need arise. I have an API that was orig…

I used to argue in favor of json-rpc as well, but I have to say that I have allied with the dark side now. if for no other reason than caching, with REST you have fine control over what addressable resources get cached and which do not. This is huge for performance in some systems. I have found once you use REST semantics in earnest to build an application, it is hard to levy argument against it. So much of the webs…

It's possible my perspective is skewed. I write APIs for stateful applications, so clients don't ask for the same information over and over, reducing the need/utility of browser caching. I can see how REST would help solve the caching problem.

Re: Common REST Mistakes

#36

Post by kmt »

daredevildave wrote: post #34
kmt wrote: post #15

Earlier quoted context omitted.

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

Cookie-based authentication is generally only applicable to the browser interface. From my point of view where REST really shines is at the API level. HTTP authentication while not particularly great in the browser ( mainly because of UI/logging out issues ) is good at the API level where you send your credentials with each request.

What if you have to serve both interactive users and automatic clients? Would you use the url structure for both or would you have a separate api structure?

Re: Common REST Mistakes

#37

Post by [deleted] »

sabat wrote: post #21
petercooper wrote: post #8

I believe #3 is actually a cornerstone of modern Ruby on Rails usage :-)

I have not read Roy Fielding's dissertation, and so I am speaking out of partial ignorance. But isn't most of this the opposite of what REST is supposed to be? URLs aren't supposed to represent resources? Whahh?

[deleted]

Re: Common REST Mistakes

#38

Post by gthank »

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

The HTTP spec includes the Basic and Digest methods of auth.

Re: Common REST Mistakes

#39

Post by derefr »

daredevildave wrote: post #34
kmt wrote: post #15

Earlier quoted context omitted.

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

Cookie-based authentication is generally only applicable to the browser interface. From my point of view where REST really shines is at the API level. HTTP authentication while not particularly great in the browser ( mainly because of UI/logging out issues ) is good at the API level where you send your credentials with each request.

> HTTP authentication while not particularly great in the browser ( mainly because of UI/logging out issues )

You know, with all the little browser-chrome experiments that have been going on lately, I'm really surprised that no one has tried to make HTTP-authentication-based login/logout/account management as painless as HTML-served variants. I'd imagine that it would couple with the little "lock" icon in the URL/status bar, making it have four states instead of two: "insecure, secure, insecurely logged in, and securely logged in" where clicking on it brings up a menu to both view credentials and change your password/edit profile/log out/close account/sign up/anything else browser makers want to implement. (They could be distinct, of course, but I like the idea of making "insecure" look scary so that users would be deterred from sending credentials through it.

Re: Common REST Mistakes

#40

Post by Vitaly »

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…

the idea is that instead of documenting your project list to be at /projects/ and individual projects to be at /projects/PROJECT_ID you should have a SINGLE entry point into your API which should have LINKS to your various services.

so you will have something like

    
      http://../projects/
      http://../users
or even this:

    
      projects
      http://.../projects/
    
    ...
and then your project list should not just return you projects ids to construct a url with, instead it should provide you full urls to access the relevant resources.

The rule of thumb is: with a PROPER REST API you should never do any "url generation", you should get ALL your urls (except for the SINGLE entry one) form the API.

check out this link for some more info: http://www.theamazingrando.com/blog/?p=107

Post reply on HN