Why and How You Should Write REST-Centric Applications
1–10 of 33 posts
Re: Why and How You Should Write REST-Centric Applications
#2Seems like the Rails guys have done a good job sorting all these issues out.
Re: Why and How You Should Write REST-Centric Applications
#3Nice post. The single biggest criticism I usually level at REST implementations is the lack of HATEOAS - the discoverability aspect of REST is about more than just an easily understood URI. As the author of this post states in his 2nd bullet point (emphasis mine):
"It’s expressive, REST paths and CRUD requests are easy to understand _and hypermedia makes it easy to navigate_"
It's that second part that so many implementations gloss completely over, it's probably worth discussing that separately in the same way that authentication is discussed in the post.
Re: Why and How You Should Write REST-Centric Applications
#4RESTful APIs can be a pain when you have to mashup different APIs, though. The amount of calls you end up having to do can be quite a lot. From a backend standpoint it's not that bad if you cache, but from a consumer standpoint I have to get a /users/active list, iterate over them, then call a /friends/[id] call for every user. If you add a third list you can easily see how annoying it might be. It's great that your APIs can be so flexible but now your clients are writing completely different code all over... the chances of you breaking something or them having to re-code things every release is a lot greater than updating a getFriendsOfActiveUsers traditional API call. Has anyone else found this to be the case? Are there ways around it? I'd almost want a hybrid or a mash API that I can pass in URLs and have it return a mashup for me.
Re: Why and How You Should Write REST-Centric Applications
#5Nice post. The single biggest criticism I usually level at REST implementations is the lack of HATEOAS - the discoverability aspect of REST is about more than just an easily understood URI. As the author of this post states in his 2nd bullet point (emphasis mine): "It’s expressive, REST paths and CRUD requests are easy to understand _and hypermedia makes it easy to navigate_" It's that second part that so many implem…
I agree that this is often glossed over. In fact I can't think of any framework implementation that provides it.
About the best example I can think of is the Atom publishing protocol where a service links to it's publishing URLs and a feed can provide pagination through hyperlinks. But still it is not a particularly sophisticated example, do you know of any others?
Re: Why and How You Should Write REST-Centric Applications
#6Nice post. The single biggest criticism I usually level at REST implementations is the lack of HATEOAS - the discoverability aspect of REST is about more than just an easily understood URI. As the author of this post states in his 2nd bullet point (emphasis mine): "It’s expressive, REST paths and CRUD requests are easy to understand _and hypermedia makes it easy to navigate_" It's that second part that so many implem…
I agree that this is often glossed over. In fact I can't think of any framework implementation that provides it. About the best example I can think of is the Atom publishing protocol where a service links to it's publishing URLs and a feed can provide pagination through hyperlinks. But still it is not a particularly sophisticated example, do you know of any others?
[deleted]
Re: Why and How You Should Write REST-Centric Applications
#7Nice post. The single biggest criticism I usually level at REST implementations is the lack of HATEOAS - the discoverability aspect of REST is about more than just an easily understood URI. As the author of this post states in his 2nd bullet point (emphasis mine): "It’s expressive, REST paths and CRUD requests are easy to understand _and hypermedia makes it easy to navigate_" It's that second part that so many implem…
The best example of that is a website. It provides links to other documents. It just happens to be that the output is usually HTML, but there's no reason why JSON or XML can't contain links to other hypermedia as well.
Re: Why and How You Should Write REST-Centric Applications
#8Using HTTP status codes for error messaging leaves quite a bit to be desired. You don't have that many options beyond a handful in the 4xx (400, 404, 409) and 5xx (500, 503) range. For the most part, they are either really general or too specific to be correctly used. It'd be nice if there were a standard for supplemental error messages.
Edit: (to the downvoter) this post explicitly mentioned "You get clean exception handling via HTTP status codes". The exception handling may be clean, but it's extremely coarse.
Re: Why and How You Should Write REST-Centric Applications
#9[deleted]
Re: Why and How You Should Write REST-Centric Applications
#10[deleted]
The server itself can and does catch the signal that indicates the user hit Stop. Whether or not your code can detect this -- that's the tricky part.