REST is over(blog.steveklabnik.com)
blog.steveklabnik.com
REST is over
http://blog.steveklabnik.com/posts/2012-02-23-rest-is-over
15 comments
See, this is the problem with REST: just when you think you've finally grokked it and are building RESTfully, along comes yet another hurdle hidden behind the others. You're not really RESTful unless you also do X, where X is a seemingly infinite regress of progressively more pure necessary criteria that curve toward an asymptote.
Seriously, why is it so hard to develop using a method that is supposed to make building web services easier?
Please note that I'm not trolling: I have spent the past year and a half trying really hard to build RESTful web services, I see and have experienced the benefits of this approach, and I think I've been getting progressively better at it.
Seriously, why is it so hard to develop using a method that is supposed to make building web services easier?
Please note that I'm not trolling: I have spent the past year and a half trying really hard to build RESTful web services, I see and have experienced the benefits of this approach, and I think I've been getting progressively better at it.
There are only six constraints to be considered RESTful, and those are reasonably well defined. Anything else is either not really a part of REST (such as having to use all HTTP methods, or having clean URLs) or derived from them.
In this case, sending some representation as just JSON (application/json) clearly breaks the Uniform Interface constraint, particularly the HATEOAS principle: a client is supposed to only know the base URL and the mimetypes. If he gets 'application/json' as a reply, how is he supposed to know what to do with it? It may be a user profile, or a blog post, or a description of an UI, etc, there's no way to tell.
In this case, sending some representation as just JSON (application/json) clearly breaks the Uniform Interface constraint, particularly the HATEOAS principle: a client is supposed to only know the base URL and the mimetypes. If he gets 'application/json' as a reply, how is he supposed to know what to do with it? It may be a user profile, or a blog post, or a description of an UI, etc, there's no way to tell.
Is there anything inherently wrong with including a type property on a json response to help with type-marshalling into an object type which both clients and servers mutually understand?
I'm assuming "wrong" means unRESTful.
Yes, because the clients have to know that for your service specifically, when they get an "application/json" response, they have to look for that property. That kind of information, unless defined in the standard - in this case, the HTTP or JSON specs - is considered out-of-band information, which breaks the Uniform Interface constraint.
To quote Roy Fielding:
Of course, I believe you could easily bypass that by making up a single new mediatype (e.g. application/vnd.my-service+json) and then use that for any JSON response with that type property. Since the clients know knew how to distinguish your JSON responses from everybody else's just by their mediatype, it wouldn't break REST.
But on the other hand, if you're using a different mediatype, why not go all the way and just use different mediatypes instead of a type property?
EDIT: As an addendum, the point of this constraint is to reduce coupling and enable the REST clients to be as generic as possible, enabling code reuse and modularity.
Using your example, I could write an application where the core was composed of an HTTP client, with support for plugins that would register themselves as "mediatype handlers". This way, the core could fetch the representation for an URL and then dispatch it to the right handler using the mediatype.
If I wanted to process your API, now my core client would have to include a JSON parser and an hack in the middle of the dispatching code to process all 'application/json' responses looking for your type property. It'd be ugly, bloated (multiple JSON parsing instances), harder to maintain, etc.
Of course, right now we don't see this as a problem because everyone writes a client against a specific API anyway, but frankly I think that's a bug, not a feature. If the REST APIs out there were truly RESTful, I think we'd see much more interesting clients that could combine dozens of different APIs, which is now impossible due to the sheer manpower required.
Yes, because the clients have to know that for your service specifically, when they get an "application/json" response, they have to look for that property. That kind of information, unless defined in the standard - in this case, the HTTP or JSON specs - is considered out-of-band information, which breaks the Uniform Interface constraint.
To quote Roy Fielding:
A REST API should be entered with no prior knowledge beyond the initial
URI (bookmark) and set of standardized media types that are appropriate
for the intended audience
Of course, I believe you could easily bypass that by making up a single new mediatype (e.g. application/vnd.my-service+json) and then use that for any JSON response with that type property. Since the clients know knew how to distinguish your JSON responses from everybody else's just by their mediatype, it wouldn't break REST.
But on the other hand, if you're using a different mediatype, why not go all the way and just use different mediatypes instead of a type property?
EDIT: As an addendum, the point of this constraint is to reduce coupling and enable the REST clients to be as generic as possible, enabling code reuse and modularity.
Using your example, I could write an application where the core was composed of an HTTP client, with support for plugins that would register themselves as "mediatype handlers". This way, the core could fetch the representation for an URL and then dispatch it to the right handler using the mediatype.
If I wanted to process your API, now my core client would have to include a JSON parser and an hack in the middle of the dispatching code to process all 'application/json' responses looking for your type property. It'd be ugly, bloated (multiple JSON parsing instances), harder to maintain, etc.
Of course, right now we don't see this as a problem because everyone writes a client against a specific API anyway, but frankly I think that's a bug, not a feature. If the REST APIs out there were truly RESTful, I think we'd see much more interesting clients that could combine dozens of different APIs, which is now impossible due to the sheer manpower required.
While I totally agree with the ideas you've described from an academic point of view, I don't that they adequately consider the human side of consuming APIs.
Yeah, it'd be awesome if we could all consume APIs with standard interfaces using Content-Types, however I don't think the current solution is realistic or even good for innovation.
Having to define a Content-Type like "application/vnd.my-service+json" and submit it to a standards body and then approved like described in Amundsen's book is hardly practical or desirable.
The standards process today sucks (see the CSS prefix debate for a prime example) (and, I'm not claiming I can do better, just making an observation)
The way I see it, defining types in a JSON format to help with type-marshalling until that format is successful and thus merits standardization is far more effective at promoting innovation than starting with submission to a standards body so that everyone can comment on (i.e. bikeshed) about a format until it gains acceptance.
There is a an interesting dynamic between pragmatism and academics, but I think it would be best for the academics to actively move the pragmatics towards the ideal instead of staying in an ivory tower and letting the pragmatics take twice as long to discover the "pure" solution.
RESTish solutions should become RESTful through standardization into a proper media type. Maybe the RESTful solution is derived from the coordinated cooperation of several participants with RESTish solutions.
Acknowledging and adopting the human element is likely to move things forward far faster than a steadfast insistence on being pure. We could probably have far more useful media types if we assumed that formats eventually become a media type once they become popular enough. Pave the cowpaths.
Anyways, not arguing with your comment. I agree with most of what you said and ot was enlightening. Just saying, that it'd be great if people actively considered the fact that human beings are involved when discussing ideas. Ideas are great, but they mean nothing if you can't humans to go along with them.
Yeah, it'd be awesome if we could all consume APIs with standard interfaces using Content-Types, however I don't think the current solution is realistic or even good for innovation.
Having to define a Content-Type like "application/vnd.my-service+json" and submit it to a standards body and then approved like described in Amundsen's book is hardly practical or desirable.
The standards process today sucks (see the CSS prefix debate for a prime example) (and, I'm not claiming I can do better, just making an observation)
The way I see it, defining types in a JSON format to help with type-marshalling until that format is successful and thus merits standardization is far more effective at promoting innovation than starting with submission to a standards body so that everyone can comment on (i.e. bikeshed) about a format until it gains acceptance.
There is a an interesting dynamic between pragmatism and academics, but I think it would be best for the academics to actively move the pragmatics towards the ideal instead of staying in an ivory tower and letting the pragmatics take twice as long to discover the "pure" solution.
RESTish solutions should become RESTful through standardization into a proper media type. Maybe the RESTful solution is derived from the coordinated cooperation of several participants with RESTish solutions.
Acknowledging and adopting the human element is likely to move things forward far faster than a steadfast insistence on being pure. We could probably have far more useful media types if we assumed that formats eventually become a media type once they become popular enough. Pave the cowpaths.
Anyways, not arguing with your comment. I agree with most of what you said and ot was enlightening. Just saying, that it'd be great if people actively considered the fact that human beings are involved when discussing ideas. Ideas are great, but they mean nothing if you can't humans to go along with them.
Having to define a Content-Type like "application/vnd.my-service+json" and submit it to a standards body and then approved like described in Amundsen's book is hardly practical or desirable.
Yeah, but that's why I chose media types in the Vendor Tree (application/vnd.) as examples - as far as I can tell, they do not need to be registered with IANA. And I'm sure they don't have to be reviewed, even if you do register them:
The way I see it, defining types in a JSON format to help with type-marshalling until that format is successful and thus merits standardization is far more effective at promoting innovation than starting with submission to a standards body so that everyone can comment on (i.e. bikeshed) about a format until it gains acceptance.
Sure, but it doesn't have to be a standard to have its own mimetype. Just put it after your company's name (application/vnd.COMPANY.FORMAT) and forget about registration, imho.
Sure, a standard would be better, but this is still way better than having to use an hack like that.
Yeah, but that's why I chose media types in the Vendor Tree (application/vnd.) as examples - as far as I can tell, they do not need to be registered with IANA. And I'm sure they don't have to be reviewed, even if you do register them:
public exposure and review of media types to be
registered in the vendor tree is not required
The way I see it, defining types in a JSON format to help with type-marshalling until that format is successful and thus merits standardization is far more effective at promoting innovation than starting with submission to a standards body so that everyone can comment on (i.e. bikeshed) about a format until it gains acceptance.
Sure, but it doesn't have to be a standard to have its own mimetype. Just put it after your company's name (application/vnd.COMPANY.FORMAT) and forget about registration, imho.
Sure, a standard would be better, but this is still way better than having to use an hack like that.
Cool beans. I'm still learning more about custom media types at the moment and this is useful info. Thanks.
You know what it reminds me allot of? MVC. MVC used to have a concrete definition in SmallTalk, Struts 1.0 adopted it fairly pure as well, but from there almost everything became MVC and MVC started to become a fairly generic term for separation of concerns. REST seems to me to be falling into the same trap where originally it was the HTTP actions, then nouns and verbs, now it seems to be expanding in scope again.
In defense of the grandparent post though, REST never specified a data or for that mater media format. It could be JSON or XML or even a binary format like a bitmap but a lot of people that talk about RESTfull services talk about JSON which is not a requirement of the original REST concept. REST was more about how a resource was accessed, not what that resource is.
In defense of the grandparent post though, REST never specified a data or for that mater media format. It could be JSON or XML or even a binary format like a bitmap but a lot of people that talk about RESTfull services talk about JSON which is not a requirement of the original REST concept. REST was more about how a resource was accessed, not what that resource is.
originally it was the HTTP actions
Not really. The web is a RESTful system, but there's nothing specific to HTTP in REST. It's just an architectural style, it doesn't specify nothing in concrete.
Not really. The web is a RESTful system, but there's nothing specific to HTTP in REST. It's just an architectural style, it doesn't specify nothing in concrete.
I understand that, but for all intents and purposes people are doing REST over HTTP, when people talk about REST and it's use on the web HTTP is implied, my use of originally was definitely not the correct word choice better verbiage would be "when it started to be used by web application developers REST was". That being said They (REST and HTTP) where envisioned together, while REST does not require HTTP, for the most part that is where it is being utilized, HTTP actions being used as the semantics to transfer the representative state.
JSON is not hypermedia, but specific formats encoded as JSON can be.
To clarify, "application/json" is not REST, but "application/foaf+json" can very well be.
To clarify, "application/json" is not REST, but "application/foaf+json" can very well be.
Why do you say "Hopefully it will not become hypermedia" with respect to JSON? What's wrong with this happening? What are your thoughts on the Collection+JSON hypermedia type presented in Amundsen's book?
http://www.amundsen.com/media-types/collection/
I'm sorry, but "hypermedia" is a terrible term. You might call a webpage a kind of hypermedia, but web API's accessed via HTTP? That makes no sense at all. Hypermedia is a huge umbrella term which describes content, not a means for sending and retrieving data!
Steve left out some context regarding what hypermedia API entails. I believe the essence of a hypermedia API is that the client does not construct URLs but instead follows links. Only the server constructs URLs, and the only URL the client should be aware of (that was not generated by the server and delivered in an HTTP response) is the initial URL.
Hyper anything sounds terribly retro to me, circa 1992.
But I agree: it is an uninformative term for anything which merely establishes a connection and sends/receives data as opposed to specifically delivering content.
REST is just fine as it is. It is a well-understood term for what it does. Why reinvent the wheel and stick a new label on it every five minutes?
But I agree: it is an uninformative term for anything which merely establishes a connection and sends/receives data as opposed to specifically delivering content.
REST is just fine as it is. It is a well-understood term for what it does. Why reinvent the wheel and stick a new label on it every five minutes?
REST is well understood? The percentage of self-described REST APIs that actually respect its constraints is almost a rounding error.
Well, I'd probably agree with that. There are some truly bizarro API implementations.
I think the term "hypermedia" will catch on just like REST did. People will begin to slap on the hypermedia label to their APIs whether or not they are true hypermedia APIs. Developing hypermedia APIs will be the new craze until some other revolutionary terminology is introduced to describe yet another way to correctly develop APIs.
Yes, this is how the world works. Some people push ideas forward. Others jump on for the ride. I fail to see a problem with this though. It's the job of those pushing the ideas forward to communicate effectively about what they are doing so that we can determine which followers are doing the right thing.
The article is Ok, but posting "REST is OVER" is obvious flame bait. People need to stop doing this on HN.
Talk about bad branding. 'Hypermedia' sounds like something from a Gibson novel.
It's still a better word than 'HATEOAS' (Hypermedia As The Engine Of Application State), which has to be in the running for worst acronym ever.
I have to say, the article itself was so abstract I hardly found it worth reading. I did, however, check out the book mentioned in this article. A nice paragraph from the foreword sort of defines hypermedia:
"The World Wide Web is driven by hypermedia: the ability of a document to describe its possible states, and its relationship to other documents. Hypermedia is not just a way of making websites that average people can use; it’s a new style for distributed computing, powerful and flexible."
"The World Wide Web is driven by hypermedia: the ability of a document to describe its possible states, and its relationship to other documents. Hypermedia is not just a way of making websites that average people can use; it’s a new style for distributed computing, powerful and flexible."
While the title is link bait, the author has a point and I think it was best summed up by his use of the word RESTish. Absolute adherence to REST nouns in every application is similar to the old over normalizing in relational databases some times it does not fit the need. But that does not make the concept null and void it just means that it is a good rule of thumb, to be broken when the situation calls for a different rule.
What do you mean by "REST nouns"?
This will go into detail far more than I can in a post. http://www.subbu.org/blog/2008/04/nouns-and-resources but the tl;dr is REST nouns are a construct in which you identify all of your objects in a system, these become your REST endpoints such as User in which you have GET, POST, PUT, DELETE each of these verbs causing a specific action on the object or noun. This works great for a large portion of the application but there are some areas such as transactions where it is very hard to logically turn the action into a noun and make it understandable. Sometimes we need the back end to orchestrate multi-step actions and the noun construct just does not convey the workflow. When this happens some people choose to use verb systematic such as generatePDF while still maintaining the REST HTTP actions while others tend to strictly adhere to making said process a noun which can effect readability.
[deleted]
First time I heard the term "hypermedia".
It's in the first line of the REST chapter[1] of the original thesis:
[1]: http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch...
[2]: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte...
(...) Representational State Transfer (REST) architectural style for distributed
hypermedia systems (...)
[1]: http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch...
[2]: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte...
It's from the 60s, when hypertext was invented: http://en.wikipedia.org/wiki/Hypermedia
There's also a good presentation here:
http://www.slideshare.net/trilancer/why-hateoas-1547275
http://www.slideshare.net/trilancer/why-hateoas-1547275
http://bikeshed.org/
when you cannot think of any other way to improve something, suggest a name change!
when you cannot think of any other way to improve something, suggest a name change!
The author of this blog post is either confused about the subject or doesn't know how to express his thoughts.
This article from Roy Fielding is much better: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte... The comments are also helpful.
This article from Roy Fielding is much better: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte... The comments are also helpful.
I'm waiting for 'cybermedia' myself.
These days, I've taken to calling them HTTP web services (as opposed to RPC over HTTP).
These days? That's what we called them in 2001. ;-)
Looks more like REST 2.0.
Is this a sarcasm or what?
Have you read the actual blog post?
I imagine he has, but hypermedia already generally means hypertext documents. JSON with some URLs in it (which I think the article means - but I'm not sure) is something very different.
Yes sure I read it. But could not get what it means.
It means "Nobody understands REST and it has been so misused that it has lost its usefulness as a term, let's create a new term for the original concept, a term that better reflects what REST really means". That term is Hypermedia APIs.
No.. no.. no.. replace REST with SOAP, and I can go along with it.
The reason that I bring this up, and have harped on this before, is that when most people design REST they are using HTTP + JSON. The problem is that JSON is not hypermedia. Hopefully it will not become hypermedia. As a result, the systems that are HTTP + JSON are not REST. They are RESTish, but not REST.
I think that the terms really have value. That is the purpose of language. If we go about calling things that use POST or Get or PUT + JSON hypermedia, we can start to misapply the thoughts of the thesis. If we don't stick to the terms, we can not hope to properly understand the thesis' context and its fundamental goal of synthesizing lessons learned by Roy in how to design a better Internet infrastructure.