4 ms·

Explaining REST to Damien Katz

51 points by baha_man 18y ago

tptacek 18y ago
Apropos nothing, Dare Obasanjo needs to seriously reconsider the use of boldface as his link style.
- gigawatt 18y ago
  Equally apropos of nothing, I saw his tagline and decided to never read anything on his site. Marketing yourself as an alcoholic pothead programmer seems a strange choice. Perhaps I judge too soon?
  - pius 18y ago
    Perhaps I judge too soon? Yes.
paul 18y ago
Part of the problem with these REST discussions is that the definition of what is being discussed keeps shifting. The reasonable bits of REST are, well, reasonable, and generally non-controversial. Most of what he describes in this post is fairly reasonable, but his previous REST post (that I mentioned as silly) focused on the less reasonable (and more dogmatic) parts. He criticized APIs for such things as, "REST API Sin #1: URIs Identify Methods Instead of Resources (The Original Sin)". Referring to design decisions as "sins" may be cute, but it's also a clue that you may be drifting away from pragmatism and towards religion.
- tlrobinson 18y ago
  Agreed. I think there's a couple issues that cause confusion. Yes, REST advocates say your URLs should be for "resources" not "methods", but sometimes the distinction is blurry. For example, a Google search: http://www.google.com/search?q=restful http://www.google.com/search?q=restful Is www.google.com/search a "resource" or a "method"? I would call it a method, but it's also sort of a resource. I can't think of any way to make it more "resource oriented".
  - jsdalton 18y ago
    It's more like a collection or list of resources, and the search term is a filter on that collection.
  - bct 18y ago
    > Is www.google.com/search a "resource" or a "method"? You can look at it either way, but it's a perfectly fine resource.
- sh1mmer 18y ago
  Well yes, that is sort of true. But, if it were most other subjects people wouldn't give a crap. It's hard to say what it is about pure REST that works people up so much. I think, perhaps, it's hard for people to be told they don't get REST when they thought they did but were actually doing a REST-RPC hybrid.
  - tlrobinson 18y ago
    "It's hard to say what it is about pure REST that works people up so much." I think a comment on Damien's blog summed it up nicely: "I love living in the modern age. It's so refreshing to have moved from religious fights based on the Bible to religious fights based on RFCs."
  - paul 18y ago
    The thing is, there's nothing wrong with doing REST-RPC hybrid. The reasonable parts of REST (like making things stateless, using http error codes, etc) are just as reasonable with RPC, and often RPC is the right way to approach an API (better than pure REST).
    - sh1mmer 18y ago
      But you don't get benefits like addressability and caching. REST advocates have been repeatedly been accused of being religious, but I'm citing reasons you are just saying "and often RPC is the right way to approach an API (better than pure REST)". Which gives meaning to rightness at all. The "religion" in this debate has nothing to do with any style of architecture, it's simply the rigour people choose to put in to their arguments. I won't support a bad argument for REST any more than I'll support a bad one for anything else.
      - paul 18y ago
        The GET side of REST is usually reasonable and non-controversial. It's the other verbs where things get crazy, with people arguing that you should PUT comments to a document instead of doing a POST to /addcomment (because add comment is a verb). I gave some examples on the other thread showing how the supposed caching benefits are largely imaginary (beyond simple GET caching), and simple RPC is easier to deal with (because you aren't limiting yourself to 5 verbs).
greenagain 18y ago
I think that Damien's point is that he doesn't get the "self-evidence" or Good Thinginess of using REST as a _developer_ of a web application. I see it over and over again in development situations: As soon as the topic of webservices comes up, someone starts crying, "REST! REST! OMG, REST!" And that's usually before they've even heard what the web service will do. It's funny: When REST advocates are pressed about how REST might not be the best choice for every, single development effort, they either: 1. Simply regurgitate REST's tenants 2. Deny that they are regurgitating REST's tenants, and then go on to regurgitate REST's tenants I think that everyone can acknowledge the good of using REST as a _user_ of a web application -- which is what the REST literature addresses anyway. But is REST going help app developers deliver features in a timely manner? Is it the most agile way to develop? Not necessarily. <controversial>If you follow REST to its purist implications, you probably wouldn't have a dynamic web application at all. Instead, you'd have a interlinked mesh of of hand-written HTML pages that cover every representation of the application. Hello, Early Web!</controversial> So anyway, if REST works for you, awesome; as long as you've designed your resources and interfaces intelligibly, you're helping to make the waters of the internet easier to navigate. It SOAP/RPC isn't working for you, maybe you should try REST. But if SOAP/RPC is serving you just fine, don't let this topic rock your boat.
sabat 18y ago
For the record, Dave Winer didn't come up with SOAP, and didn't do with a "bunch of folks from Microsoft". SOAP sucks and it's largely due to MS' influence, but Winer merely came up with XML-RPC, which is pretty close to Damien's idea that maybe POST is enough. Not that I'm a Winer fan -- his behavior oddly reflects his surname -- but facts is facts. Dave understands the need for simplicity, and needless to say, the SOAP folks don't.

51 points by baha_man 18y ago

tptacek 18y ago

Apropos nothing, Dare Obasanjo needs to seriously reconsider the use of boldface as his link style.

gigawatt 18y ago
Equally apropos of nothing, I saw his tagline and decided to never read anything on his site. Marketing yourself as an alcoholic pothead programmer seems a strange choice. Perhaps I judge too soon?
- pius 18y ago
  Perhaps I judge too soon? Yes.

paul 18y ago

Part of the problem with these REST discussions is that the definition of what is being discussed keeps shifting. The reasonable bits of REST are, well, reasonable, and generally non-controversial. Most of what he describes in this post is fairly reasonable, but his previous REST post (that I mentioned as silly) focused on the less reasonable (and more dogmatic) parts. He criticized APIs for such things as, "REST API Sin #1: URIs Identify Methods Instead of Resources (The Original Sin)". Referring to design decisions as "sins" may be cute, but it's also a clue that you may be drifting away from pragmatism and towards religion.

tlrobinson 18y ago
Agreed. I think there's a couple issues that cause confusion. Yes, REST advocates say your URLs should be for "resources" not "methods", but sometimes the distinction is blurry. For example, a Google search: http://www.google.com/search?q=restful http://www.google.com/search?q=restful Is www.google.com/search a "resource" or a "method"? I would call it a method, but it's also sort of a resource. I can't think of any way to make it more "resource oriented".
- jsdalton 18y ago
  It's more like a collection or list of resources, and the search term is a filter on that collection.
- bct 18y ago
  > Is www.google.com/search a "resource" or a "method"? You can look at it either way, but it's a perfectly fine resource.
sh1mmer 18y ago
Well yes, that is sort of true. But, if it were most other subjects people wouldn't give a crap. It's hard to say what it is about pure REST that works people up so much. I think, perhaps, it's hard for people to be told they don't get REST when they thought they did but were actually doing a REST-RPC hybrid.
- tlrobinson 18y ago
  "It's hard to say what it is about pure REST that works people up so much." I think a comment on Damien's blog summed it up nicely: "I love living in the modern age. It's so refreshing to have moved from religious fights based on the Bible to religious fights based on RFCs."
- paul 18y ago
  The thing is, there's nothing wrong with doing REST-RPC hybrid. The reasonable parts of REST (like making things stateless, using http error codes, etc) are just as reasonable with RPC, and often RPC is the right way to approach an API (better than pure REST).
  - sh1mmer 18y ago
    But you don't get benefits like addressability and caching. REST advocates have been repeatedly been accused of being religious, but I'm citing reasons you are just saying "and often RPC is the right way to approach an API (better than pure REST)". Which gives meaning to rightness at all. The "religion" in this debate has nothing to do with any style of architecture, it's simply the rigour people choose to put in to their arguments. I won't support a bad argument for REST any more than I'll support a bad one for anything else.
    - paul 18y ago
      The GET side of REST is usually reasonable and non-controversial. It's the other verbs where things get crazy, with people arguing that you should PUT comments to a document instead of doing a POST to /addcomment (because add comment is a verb). I gave some examples on the other thread showing how the supposed caching benefits are largely imaginary (beyond simple GET caching), and simple RPC is easier to deal with (because you aren't limiting yourself to 5 verbs).

greenagain 18y ago

I think that Damien's point is that he doesn't get the "self-evidence" or Good Thinginess of using REST as a _developer_ of a web application. I see it over and over again in development situations: As soon as the topic of webservices comes up, someone starts crying, "REST! REST! OMG, REST!" And that's usually before they've even heard what the web service will do. It's funny: When REST advocates are pressed about how REST might not be the best choice for every, single development effort, they either: 1. Simply regurgitate REST's tenants 2. Deny that they are regurgitating REST's tenants, and then go on to regurgitate REST's tenants I think that everyone can acknowledge the good of using REST as a _user_ of a web application -- which is what the REST literature addresses anyway. But is REST going help app developers deliver features in a timely manner? Is it the most agile way to develop? Not necessarily. <controversial>If you follow REST to its purist implications, you probably wouldn't have a dynamic web application at all. Instead, you'd have a interlinked mesh of of hand-written HTML pages that cover every representation of the application. Hello, Early Web!</controversial> So anyway, if REST works for you, awesome; as long as you've designed your resources and interfaces intelligibly, you're helping to make the waters of the internet easier to navigate. It SOAP/RPC isn't working for you, maybe you should try REST. But if SOAP/RPC is serving you just fine, don't let this topic rock your boat.

sabat 18y ago

For the record, Dave Winer didn't come up with SOAP, and didn't do with a "bunch of folks from Microsoft". SOAP sucks and it's largely due to MS' influence, but Winer merely came up with XML-RPC, which is pretty close to Damien's idea that maybe POST is enough. Not that I'm a Winer fan -- his behavior oddly reflects his surname -- but facts is facts. Dave understands the need for simplicity, and needless to say, the SOAP folks don't.