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

Why and How You Should Write REST-Centric Applications

w2lessons.com

Post reply on HN
Print view View original

11–20 of 33 posts

Re: Why and How You Should Write REST-Centric Applications

#11

Post by extension »

seangeo wrote: post #5
sradnidge wrote: post #3

Nice 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?

I'm not sure how HATEOAS could be bundled into a framework as there is no straightforward process for realizing it. Designing a generic hypermedia format is a huge undertaking and a RESTful service must be almost completely specified by such formats.

If you can implement your service entirely with existing formats, that could make things much simpler. But the only kind of hypermedia for machine data access that I've ever heard of is RDF, and there is nothing simple about that.

Re: Why and How You Should Write REST-Centric Applications

#12

Post by [deleted] »

clarkevans wrote: post #8

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

[deleted]

Re: Why and How You Should Write REST-Centric Applications

#13

Post by [deleted] »

[deleted] wrote: post #12
clarkevans wrote: post #8

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

[deleted]

[deleted]

Re: Why and How You Should Write REST-Centric Applications

#14

Post by extension »

leftnode wrote: post #7
sradnidge wrote: post #3

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

Most any document format can contain links, but that doesn't make it hypermedia. You can't make a client that knows what to do with any JSON or XML document.

Re: Why and How You Should Write REST-Centric Applications

#15

Post by notJim »

sradnidge wrote: post #3

Nice 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 wrote an api that has HATEOAS, but none of the devs really use it. They seem to prefer hardcoding strings.

Re: Why and How You Should Write REST-Centric Applications

#16

Post by DocSavage »

I was introduced to RESTful APIs when Rails started championing them. And while I've read a number of REST articles, it still seems like I'm not understanding the nuances of long-term vs short-term decoupling of client/server to the level that Fielding demands for REST. For example, there's his blog entry here:

http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte...

A key point is this paragraph:

"A REST API should spend almost all of its descriptive effort in defining the media type(s) used for representing resources and driving application state, or in defining extended relation names and/or hypertext-enabled mark-up for existing standard media types. Any effort spent describing what methods to use on what URIs of interest should be entirely defined within the scope of the processing rules for a media type (and, in most cases, already defined by existing media types). [Failure here implies that out-of-band information is driving interaction instead of hypertext.]"

---

When I try to absorb this and other points in that blog entry, I feel like I've failed to understand the real lessons and I'm thinking too short-term with fixed URIs for CRUD on data. But then again, in the comments, Fielding says "REST is software design on the scale of decades: every detail is intended to promote software longevity and independent evolution. Many of the constraints are directly opposed to short-term efficiency."

This makes a lot of sense to me and suggests that truly RESTful design isn't necessarily the best fit for people who want to throw stuff up on the web and then evolve to a more stable API.

Re: Why and How You Should Write REST-Centric Applications

#17

Post by leftnode »

extension wrote: post #14
leftnode wrote: post #7

Earlier quoted context omitted.

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.

Most any document format can contain links, but that doesn't make it hypermedia. You can't make a client that knows what to do with any JSON or XML document.

Wait, why not? The JSON could return in a standard format that the client knows where to look for links to other documents.

Re: Why and How You Should Write REST-Centric Applications

#18

Post by extension »

leftnode wrote: post #17
extension wrote: post #14

Earlier quoted context omitted.

Most any document format can contain links, but that doesn't make it hypermedia. You can't make a client that knows what to do with any JSON or XML document.

Wait, why not? The JSON could return in a standard format that the client knows where to look for links to other documents.

Sure, you can design a standard format on top of JSON, but that is rarely done. The whole appeal of it is for passing around ad-hoc data structures.

There are many hypermedia formats built on XML, but when it's just used as a data container for an API, it's not hypermedia.

Re: Why and How You Should Write REST-Centric Applications

#19

Post by notJim »

methodin wrote: post #4

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

This is an issue I'd like see more people talk about in REST API design. There's quite a balance to be struck between the number of calls to be made and the size of the data that needs to be download.

I designed a REST API that's primarily (well, currently only) used for mobile applications, and it was often hard to decide whether to “denormalize“ the API (fewer API calls required, but more data per call) or provide very general fine-grained resources.

Post reply on HN