3 ms·

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 o

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.

kls 15y ago
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.
- icebraining 15y ago
  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.
  - kls 15y ago
    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.
icebraining 15y ago
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.
- malandrew 15y ago
  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?
  - icebraining 15y ago
    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: 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 Anything besides (URL, mediatypes) is unRESTful. 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.

kls 15y ago

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.

icebraining 15y ago
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.
- kls 15y ago
  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.

icebraining 15y ago

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.

malandrew 15y ago
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?
- icebraining 15y ago
  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: 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 Anything besides (URL, mediatypes) is unRESTful. 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.