31–40 of 48 posts
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 differe…
What do you mean by "REST nouns"?
First time I heard the term "hypermedia".
These days, I've taken to calling them HTTP web services (as opposed to RPC over HTTP).
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 differe…
What do you mean by "REST nouns"?
The point is correct. Page 39 or 40 of the original thesis, if you get the PDF version, says that the goal of the thesis is to provide a mechanism to build hypermedia systems. This usage is key. The system that you make using REST needs to provide all of the "linking" ability within the response. It also assumes (Roy never defined what hypermedia is) that the content type is described somewhere, possibly in some stan…
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 buildin…
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.
Earlier quoted context omitted.
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 buildin…
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…
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.
The point is correct. Page 39 or 40 of the original thesis, if you get the PDF version, says that the goal of the thesis is to provide a mechanism to build hypermedia systems. This usage is key. The system that you make using REST needs to provide all of the "linking" ability within the response. It also assumes (Roy never defined what hypermedia is) that the content type is described somewhere, possibly in some stan…
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 buildin…
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.
when you cannot think of any other way to improve something, suggest a name change!
Earlier quoted context omitted.
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…
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.
This article from Roy Fielding is much better: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte... The comments are also helpful.