5 ms·

I'm not so sure the OP's argument is substantive. I don't know whether Roy intended that his architectural style, described in his thesis, to become a loosely d

by sabat 14y ago

I'm not so sure the OP's argument is substantive. I don't know whether Roy intended that his architectural style, described in his thesis, to become a loosely defined web service 'protocol', but we're not really making everything up as we go along. A well-implemented REST API is far and away simpler to understand (and easier to use) than a SOAP counterpart.

alpb 14y ago
Can you elaborate "a well-implemented REST API is far and away simpler to understand" statement, please? Or do you have some examples or points that may make things clear for me? Thanks in advance.
- arethuza 14y ago
  From my own experience, a decent RESTful API is perfectly easy to use from the command line using curl. Try that with with a SOAP interface!
  - alpb 14y ago
    Yeah, that's what I was thinking. I am just curious how a proper REST API looks different than Github, Stripe or other startups implemented.
    - fusiongyro 14y ago
      I saw an article a while back advocating that when you hit, say, a search resource, it should return links to the next page, so, if you hit /comments/?name=alpb&perPage=10, you might get: <comments nextPage="/comments/?name=alpb&perPage=10&page=2"> ... </comments> There's so many ways to include results though. One way would be: <comment href="/comments/2398293">Text of comment</comment> You could also do: <comment>/comments/2398293</comment> There's no standard way of getting across what a link is to another resource, or where that information should go. I don't think this is, in practice, a huge deal, because people don't write generic consumers of RESTful APIs. At some point you need to actually know what it is you're trying to do and code for it. On top of that, with RDF or XLink or XPointer and whatnot there probably are standards for doing this kind of thing, but nobody knows them, uses them or follows them.
      - davedx 14y ago
        Yup, that's HATEOAS: using hypertext to inform your clients about the state of the application (where they are, and what they can do next from this point).
        fusiongyro 14y ago
        My favorite acronym of all time.
      - jalfresi 14y ago
        "There's no standard way of getting across what a link is to another resource, or where that information should go." That doesn't quite mesh with my understanding. Some media types support hyperlinks, like HTML, which describe how links should be included (anchors, forms and link elements). For media types that don't support hyperlinks, such as images, video etc; you can use the HTTP header Link (http://www.w3.org/wiki/LinkHeader http://www.w3.org/wiki/LinkHeader). Both these methods support the relationship attribute allowing you to specify the relationship between resources thus documenting the way clients should interact with such linked hypermedia (e.g. the HTML media type specifies that Link elements with the rel attribute should perform a HTTP GET request to the indicated resource). In the example you gave, you could use a rel attribute like "comment" and link to the comments. RESTful clients could then follow the hyperlinks to the comments, knowing how to interact with them and what to do: <link rel="comment" href="/comments/2398293"/>
        fusiongyro 14y ago
        Right, but unless your resources adhere to some other standard, there's no reason why the downstream consumer would expect to find URLs in certain places or know what to do with them if they were there. Again, I don't see this as a problem, though the OP does.
wanderr 14y ago
That's a bit of a false dichotomy though. SOAP is a giant turd, but it's not the only alternative out there. JSON-RPC is just as easy to understand as REST, without all the pedantry.
- fusiongyro 14y ago
  One advantage of REST, I don't know if it's especially meaningful in this context, is that RPC mechanisms encourage people to think of remote calls as local, but remote calls have a lot more failure modes than local ones do. REST keeps you aware that you're dealing with remote resources the whole time.
- davedx 14y ago
  Most of us don't worry about pedantry too much. We try to stick to best practices - just like with the rest of development we do - and get on with it.
- sabat 14y ago
  JSON-RPC is just as easy to understand as REST, without all the pedantry. I hadn't heard of that, but it sounds exciting, partly because it's so self-explanatory.
deleted 14y ago
[deleted]

by sabat 14y ago

alpb 14y ago

Can you elaborate "a well-implemented REST API is far and away simpler to understand" statement, please? Or do you have some examples or points that may make things clear for me? Thanks in advance.

arethuza 14y ago
From my own experience, a decent RESTful API is perfectly easy to use from the command line using curl. Try that with with a SOAP interface!
- alpb 14y ago
  Yeah, that's what I was thinking. I am just curious how a proper REST API looks different than Github, Stripe or other startups implemented.
  - fusiongyro 14y ago
    I saw an article a while back advocating that when you hit, say, a search resource, it should return links to the next page, so, if you hit /comments/?name=alpb&perPage=10, you might get: <comments nextPage="/comments/?name=alpb&perPage=10&page=2"> ... </comments> There's so many ways to include results though. One way would be: <comment href="/comments/2398293">Text of comment</comment> You could also do: <comment>/comments/2398293</comment> There's no standard way of getting across what a link is to another resource, or where that information should go. I don't think this is, in practice, a huge deal, because people don't write generic consumers of RESTful APIs. At some point you need to actually know what it is you're trying to do and code for it. On top of that, with RDF or XLink or XPointer and whatnot there probably are standards for doing this kind of thing, but nobody knows them, uses them or follows them.
    - davedx 14y ago
      Yup, that's HATEOAS: using hypertext to inform your clients about the state of the application (where they are, and what they can do next from this point).
      - fusiongyro 14y ago
        My favorite acronym of all time.
    - jalfresi 14y ago
      "There's no standard way of getting across what a link is to another resource, or where that information should go." That doesn't quite mesh with my understanding. Some media types support hyperlinks, like HTML, which describe how links should be included (anchors, forms and link elements). For media types that don't support hyperlinks, such as images, video etc; you can use the HTTP header Link (http://www.w3.org/wiki/LinkHeader http://www.w3.org/wiki/LinkHeader). Both these methods support the relationship attribute allowing you to specify the relationship between resources thus documenting the way clients should interact with such linked hypermedia (e.g. the HTML media type specifies that Link elements with the rel attribute should perform a HTTP GET request to the indicated resource). In the example you gave, you could use a rel attribute like "comment" and link to the comments. RESTful clients could then follow the hyperlinks to the comments, knowing how to interact with them and what to do: <link rel="comment" href="/comments/2398293"/>
      - fusiongyro 14y ago
        Right, but unless your resources adhere to some other standard, there's no reason why the downstream consumer would expect to find URLs in certain places or know what to do with them if they were there. Again, I don't see this as a problem, though the OP does.

wanderr 14y ago

That's a bit of a false dichotomy though. SOAP is a giant turd, but it's not the only alternative out there. JSON-RPC is just as easy to understand as REST, without all the pedantry.

fusiongyro 14y ago
One advantage of REST, I don't know if it's especially meaningful in this context, is that RPC mechanisms encourage people to think of remote calls as local, but remote calls have a lot more failure modes than local ones do. REST keeps you aware that you're dealing with remote resources the whole time.
davedx 14y ago
Most of us don't worry about pedantry too much. We try to stick to best practices - just like with the rest of development we do - and get on with it.
sabat 14y ago
JSON-RPC is just as easy to understand as REST, without all the pedantry. I hadn't heard of that, but it sounds exciting, partly because it's so self-explanatory.

deleted 14y ago

[deleted]