5 ms·

URIs matter and REST matters because people have been using them incorrectly for so long. Common mistakes like putting verbs in URIs instead of using HTTP metho

URIs matter and REST matters because people have been using them incorrectly for so long. Common mistakes like putting verbs in URIs instead of using HTTP methods. You are correct though, about the design of verbs don't matter (outside of conventions) as long as everything is done correctly.

tptacek 12y ago
Just off the top of my head: if you think of verbs exposed in URLs as a common REST mistake, you may not have fully absorbed the HATEOS concept. If you have HATEOS, you're unlikely to have verb URLs.
- k__ 12y ago
  any good resources to HATEOS?
  - metaphorm 12y ago
    well, its just wikipedia, but its actually well written page on the concept, in my opinion http://en.wikipedia.org/wiki/HATEOAS http://en.wikipedia.org/wiki/HATEOAS key concept: > "The principle is that a client interacts with a network application entirely through hypermedia provided dynamically by application servers. A REST client needs no prior knowledge about how to interact with any particular application or server beyond a generic understanding of hypermedia. By contrast, in a service-oriented architecture (SOA), clients and servers interact through a fixed interface shared through documentation or an interface description language (IDL)." a truly RESTful service that follows the HATEOAS pattern doesn't require documentation to be hosted separately. it will supply all the information necessary directly through the RESTful service.
    - k__ 12y ago
      Hm okay. The key concept I understood but I don't get how clients and servers have to be, to just "get" each other in the way HATEOAS implies.
      - icebraining 12y ago
        Think web browsers. REST was modeled after the existing web.
        hawleyal 12y ago
        REST was in the original HTTP spec. Most people were just doing it wrong the entire time until recently when it became trendy to go back to the root REST ideals. And by most people I mean everyone involved in SOAP and RPC and other nonsense like that.
        dragonwriter 12y ago
        > REST was in the original HTTP spec. No, it wasn't. Fielding's dissertation, in which REST was defined, argues that a certain set of principles were an underlying foundation of the structure of the WWW architecture in its original construction, proposes REST as a formalization of and update to those principles, and proposes further that updates to the WWW architecture should be reviewed for compliance to the REST architecture. [1] So REST is a further elaboration of a set of principles inferred from the original HTTP spec, not something present as such in the original HTTP spec. [1] http://www.ics.uci.edu/~fielding/pubs/dissertation/web_arch_domain.htm http://www.ics.uci.edu/~fielding/pubs/dissertation/web_arch_...
        MichaelGG 12y ago
        Web browsers have a human intelligence driving the interactions. API clients don't. Hence the huge gap, and as far as I can see, the rather pointlessness of HATEOAS. In fact, I'm still totally lost as to the usefulness of REST at all, except as a generic term to mean RPC over HTTP except not as clunky as SOAP. Which isn't what REST is. I've yet to see or use an API that was easier to deal with because it was REST.
        icebraining 12y ago
        The Googlebot drives REST APIs just fine, and would be impossible to write using an RPC model. I've yet to see or use an API that was easier to deal with because it was REST. Of course not, because people actually want to use RPC, and so shoehorn REST into RPC-like models, which destroy its usefulness. If you're sitting at your computer and deciding that you're now going to write a client against Service A's API, the point of REST was missed, and Service A might as well have used RPC. The point of REST is to decouple the client from the specific service, using the Uniform Interface and standard formats to allow clients to interact with any service that "speaks" the same formats. But nobody's is thinking on those terms. Everyone is still thinking that it's perfectly normal and OK to waste years of developer time rewriting the wheel, over and over again, for each new service that pops up. This is fueled by the services themselves, of course, whose companies want to use their API to lock you in. So no, while this is the normal mentality, you won't see any major gains from REST.
    - dragonwriter 12y ago
      > a truly RESTful service that follows the HATEOAS pattern doesn't require documentation to be hosted separately. It might need documentation of the special media types it relies on to be hosted separately (one place where most "REST" APIs fail to follow HATEOAS is that they reuse generic media types but rely on out-of-band descriptions of the "real" format of the data, so that a client familiar with only the media type and the data would not semantics of the resource representations being returned by the API.)
  - arethuza 12y ago
    I quite like this article from Martin Fowler on the "Richardson Maturity Model" that works up to HATEOS: http://martinfowler.com/articles/richardsonMaturityModel.html http://martinfowler.com/articles/richardsonMaturityModel.htm...
    - k__ 12y ago
      Thank you. I was expecting more from this HATEOS stuff. Everything I read before sounded like full auto-discovery of APIs. But the only thing seems to be including possible next URLs in the responses. Don't get me wrong, this is a good thing. It gives the backend devs more freedom and the frontend devs need less documentation to find out what's possible. But everyone still has to write the interfacing code to these APIs :D
      - tptacek 12y ago
        At the risk of butchering the concept for the sake of simplicity: In a HATEOS API, clients need to know exactly one entry point endpoint. Nothing else is hardcoded. There is no Python code that happens to know "if you want to add a widget to a product, you POST to /product/$X/widgets". The API itself tells you where to go. An acid test: assume your API entrypoint is /api. If your API keeps HATEOS kosher, you could in a serverside update change every other URL endpoint in the application without breaking clients, because the clients would be getting those URLs from the entrypoint URL dynamically anyways. (That's not really the point of HATEOS, but it's a side effect). There is nothing wrong with simple HTTP APIs, and a lot wrong with explicitly RPC (verb) oriented APIs in general, so adhering to REST principles isn't an absolute good. This might be the point where 'dragonwriter tells me I, too, have misunderstood HATEOS. :)
        dllthomas 12y ago
        Without breaking clients permanently. Running clients would not be able to continue their current interaction.
        tptacek 12y ago
  - dragonwriter 12y ago
    The most useful resource -- and its quite concise -- on HATEOAS is this 2008 blog post from Roy Fielding (who defined REST, so it's straight from the proverbial horse's mouth): http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte...
- hawleyal 12y ago
  I agree, that is what I was trying to say. If you are doing things correctly (fully absorbed the concept), everything will be fine and no one has to argue about REST, HTTP, and URIs.

tptacek 12y ago

Just off the top of my head: if you think of verbs exposed in URLs as a common REST mistake, you may not have fully absorbed the HATEOS concept. If you have HATEOS, you're unlikely to have verb URLs.

k__ 12y ago
any good resources to HATEOS?
- metaphorm 12y ago
  well, its just wikipedia, but its actually well written page on the concept, in my opinion http://en.wikipedia.org/wiki/HATEOAS http://en.wikipedia.org/wiki/HATEOAS key concept: > "The principle is that a client interacts with a network application entirely through hypermedia provided dynamically by application servers. A REST client needs no prior knowledge about how to interact with any particular application or server beyond a generic understanding of hypermedia. By contrast, in a service-oriented architecture (SOA), clients and servers interact through a fixed interface shared through documentation or an interface description language (IDL)." a truly RESTful service that follows the HATEOAS pattern doesn't require documentation to be hosted separately. it will supply all the information necessary directly through the RESTful service.
  - k__ 12y ago
    Hm okay. The key concept I understood but I don't get how clients and servers have to be, to just "get" each other in the way HATEOAS implies.
    - icebraining 12y ago
      Think web browsers. REST was modeled after the existing web.
      - hawleyal 12y ago
        REST was in the original HTTP spec. Most people were just doing it wrong the entire time until recently when it became trendy to go back to the root REST ideals. And by most people I mean everyone involved in SOAP and RPC and other nonsense like that.
        dragonwriter 12y ago
        > REST was in the original HTTP spec. No, it wasn't. Fielding's dissertation, in which REST was defined, argues that a certain set of principles were an underlying foundation of the structure of the WWW architecture in its original construction, proposes REST as a formalization of and update to those principles, and proposes further that updates to the WWW architecture should be reviewed for compliance to the REST architecture. [1] So REST is a further elaboration of a set of principles inferred from the original HTTP spec, not something present as such in the original HTTP spec. [1] http://www.ics.uci.edu/~fielding/pubs/dissertation/web_arch_domain.htm http://www.ics.uci.edu/~fielding/pubs/dissertation/web_arch_...
      - MichaelGG 12y ago
        Web browsers have a human intelligence driving the interactions. API clients don't. Hence the huge gap, and as far as I can see, the rather pointlessness of HATEOAS. In fact, I'm still totally lost as to the usefulness of REST at all, except as a generic term to mean RPC over HTTP except not as clunky as SOAP. Which isn't what REST is. I've yet to see or use an API that was easier to deal with because it was REST.
        icebraining 12y ago
        The Googlebot drives REST APIs just fine, and would be impossible to write using an RPC model. I've yet to see or use an API that was easier to deal with because it was REST. Of course not, because people actually want to use RPC, and so shoehorn REST into RPC-like models, which destroy its usefulness. If you're sitting at your computer and deciding that you're now going to write a client against Service A's API, the point of REST was missed, and Service A might as well have used RPC. The point of REST is to decouple the client from the specific service, using the Uniform Interface and standard formats to allow clients to interact with any service that "speaks" the same formats. But nobody's is thinking on those terms. Everyone is still thinking that it's perfectly normal and OK to waste years of developer time rewriting the wheel, over and over again, for each new service that pops up. This is fueled by the services themselves, of course, whose companies want to use their API to lock you in. So no, while this is the normal mentality, you won't see any major gains from REST.
  - dragonwriter 12y ago
    > a truly RESTful service that follows the HATEOAS pattern doesn't require documentation to be hosted separately. It might need documentation of the special media types it relies on to be hosted separately (one place where most "REST" APIs fail to follow HATEOAS is that they reuse generic media types but rely on out-of-band descriptions of the "real" format of the data, so that a client familiar with only the media type and the data would not semantics of the resource representations being returned by the API.)
- arethuza 12y ago
  I quite like this article from Martin Fowler on the "Richardson Maturity Model" that works up to HATEOS: http://martinfowler.com/articles/richardsonMaturityModel.html http://martinfowler.com/articles/richardsonMaturityModel.htm...
  - k__ 12y ago
    Thank you. I was expecting more from this HATEOS stuff. Everything I read before sounded like full auto-discovery of APIs. But the only thing seems to be including possible next URLs in the responses. Don't get me wrong, this is a good thing. It gives the backend devs more freedom and the frontend devs need less documentation to find out what's possible. But everyone still has to write the interfacing code to these APIs :D
    - tptacek 12y ago
      At the risk of butchering the concept for the sake of simplicity: In a HATEOS API, clients need to know exactly one entry point endpoint. Nothing else is hardcoded. There is no Python code that happens to know "if you want to add a widget to a product, you POST to /product/$X/widgets". The API itself tells you where to go. An acid test: assume your API entrypoint is /api. If your API keeps HATEOS kosher, you could in a serverside update change every other URL endpoint in the application without breaking clients, because the clients would be getting those URLs from the entrypoint URL dynamically anyways. (That's not really the point of HATEOS, but it's a side effect). There is nothing wrong with simple HTTP APIs, and a lot wrong with explicitly RPC (verb) oriented APIs in general, so adhering to REST principles isn't an absolute good. This might be the point where 'dragonwriter tells me I, too, have misunderstood HATEOS. :)
      - dllthomas 12y ago
        Without breaking clients permanently. Running clients would not be able to continue their current interaction.
        tptacek 12y ago
- dragonwriter 12y ago
  The most useful resource -- and its quite concise -- on HATEOAS is this 2008 blog post from Roy Fielding (who defined REST, so it's straight from the proverbial horse's mouth): http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte...
hawleyal 12y ago
I agree, that is what I was trying to say. If you are doing things correctly (fully absorbed the concept), everything will be fine and no one has to argue about REST, HTTP, and URIs.