4 ms·

Can somebody explain in one sentence why is REST a good thing? What does it bring to the party? Why is forcing every RPC call that my application makes into CRU

Can somebody explain in one sentence why is REST a good thing? What does it bring to the party? Why is forcing every RPC call that my application makes into CRUDdable objects necessarily a good thing? Frankly, I can't believe the amount of near-religious attention it's being given. You're taking an obscure aspect of HTTP (already a mind-bendingly terrible protocol in its own right) - verbs - and making it the cornerstone of your application framework.

sambeau 15y ago
REST is stateless .: is cacheable
bodhi 15y ago
> [HTTP is] a mind-bendingly terrible protocol in its own right Could you detail your thoughts on this? The more I work with HTTP, the more I get impressed with how usable it is. Granted, it's not suited for some domains...
- emperorpenguin 15y ago
  Ok, I'm being somewhat unfair. HTTP is an adequate (although overly-complex) protocol for simple document retrieval. It is unfortunate, (in my opinion), that we've used it in a whole ton of ways for which it was never intended. Have you considered some of the hacks that we have to use to make HTTP do what we want? Comet/longpoll? JSONP? Have you looked at the bajillion different ways in which browsers and proxies fail to implement caching in a consistent manner? How browsers will only allow a limited number of concurrent connections to a particular host? Have you looked at a x-www-form-urlencoded post? Do you think that's a good way to send data around? Anyway, I'm not really after a big discussion of HTTP's merits - my apologies for excessive opinionation. I am, however, interested in why so many people think REST is a magic bullet.
  - DougWebb 15y ago
    Clearly HTTP has been a complete failure...
    - emperorpenguin 15y ago
      Don't confuse ubiquity with quality. Witness: VHS, Paris Hilton.
  - bodhi 15y ago
    > Have you considered some of the hacks that we have to use to make HTTP do what we want? Right, but this sounds like blaming a nail for permanently attaching something when velcro would have been more suitable. Granted, we haven't had many other options, but to me the surprising thing is that HTTP is flexible enough that all of these hacks can be done. > I am, however, interested in why so many people think REST is a magic bullet. Human nature? ;)
    - emperorpenguin 15y ago
      > Right, but this sounds like blaming a nail Well, more accurately, I'm blaming people who think that nails are awesome and the only way to do things - and in fact we should structure all our applications by making use of a relatively obscure aspect of how nails work :)
artsrc 15y ago
REST facilitates loose coupling between clients and servers, scalability, caching, retrys etc. REST is a good thing because it provides the right abstractions for some applications. A slow, unreliable interaction with a remote server is different than an interaction with an in process function call. If ignoring this complexity is causing no problems then concentrate on what does cause you problems, then just learn enough about REST to recognize a problem in the future.
- deleted 15y ago
  [deleted]
- emperorpenguin 15y ago
  But how does REST improve scalability, caching, retrys, etc... over ANY other HTTP-request based scheme?
  - artsrc 15y ago
    Exactly which other HTTP based scheme? SOAP v1.0 tunneled everything over POST so you could not cache responses. A frequent non-restful solution is to return a domain specific id to a client and have the client 'know' that the correct URL is say http://{base}/product/{id} http://{base}/product/{id}. The restful solution is to return the URL to the client have them use it what is given rather than construct it. The restful solution allows for many product servers which are independent from the original server. This makes for looser coupling and improved scaling. REST is essentially what they were thinking, or now think they should have been thinking, when they designed HTTP. So truly honoring the spirit of HTTP gets you close to REST.
    - emperorpenguin 15y ago
      Ok - fair enough. SOAP sucks. But we've known to use GET for operations with no side-effects, and POST for operations that change stuff for many years now, without needing to attach a name to it, throw PUT/DELETE into the mix, or CRUDdifying every operation. It's the verb part that I really don't get. That, and the general level of excitement surrounding REST. Why are there so damn many articles like this one?

sambeau 15y ago

REST is stateless .: is cacheable

bodhi 15y ago

> [HTTP is] a mind-bendingly terrible protocol in its own right Could you detail your thoughts on this? The more I work with HTTP, the more I get impressed with how usable it is. Granted, it's not suited for some domains...

emperorpenguin 15y ago
Ok, I'm being somewhat unfair. HTTP is an adequate (although overly-complex) protocol for simple document retrieval. It is unfortunate, (in my opinion), that we've used it in a whole ton of ways for which it was never intended. Have you considered some of the hacks that we have to use to make HTTP do what we want? Comet/longpoll? JSONP? Have you looked at the bajillion different ways in which browsers and proxies fail to implement caching in a consistent manner? How browsers will only allow a limited number of concurrent connections to a particular host? Have you looked at a x-www-form-urlencoded post? Do you think that's a good way to send data around? Anyway, I'm not really after a big discussion of HTTP's merits - my apologies for excessive opinionation. I am, however, interested in why so many people think REST is a magic bullet.
- DougWebb 15y ago
  Clearly HTTP has been a complete failure...
  - emperorpenguin 15y ago
    Don't confuse ubiquity with quality. Witness: VHS, Paris Hilton.
- bodhi 15y ago
  > Have you considered some of the hacks that we have to use to make HTTP do what we want? Right, but this sounds like blaming a nail for permanently attaching something when velcro would have been more suitable. Granted, we haven't had many other options, but to me the surprising thing is that HTTP is flexible enough that all of these hacks can be done. > I am, however, interested in why so many people think REST is a magic bullet. Human nature? ;)
  - emperorpenguin 15y ago
    > Right, but this sounds like blaming a nail Well, more accurately, I'm blaming people who think that nails are awesome and the only way to do things - and in fact we should structure all our applications by making use of a relatively obscure aspect of how nails work :)

artsrc 15y ago

REST facilitates loose coupling between clients and servers, scalability, caching, retrys etc. REST is a good thing because it provides the right abstractions for some applications. A slow, unreliable interaction with a remote server is different than an interaction with an in process function call. If ignoring this complexity is causing no problems then concentrate on what does cause you problems, then just learn enough about REST to recognize a problem in the future.

deleted 15y ago
[deleted]
emperorpenguin 15y ago
But how does REST improve scalability, caching, retrys, etc... over ANY other HTTP-request based scheme?
- artsrc 15y ago
  Exactly which other HTTP based scheme? SOAP v1.0 tunneled everything over POST so you could not cache responses. A frequent non-restful solution is to return a domain specific id to a client and have the client 'know' that the correct URL is say http://{base}/product/{id} http://{base}/product/{id}. The restful solution is to return the URL to the client have them use it what is given rather than construct it. The restful solution allows for many product servers which are independent from the original server. This makes for looser coupling and improved scaling. REST is essentially what they were thinking, or now think they should have been thinking, when they designed HTTP. So truly honoring the spirit of HTTP gets you close to REST.
  - emperorpenguin 15y ago
    Ok - fair enough. SOAP sucks. But we've known to use GET for operations with no side-effects, and POST for operations that change stuff for many years now, without needing to attach a name to it, throw PUT/DELETE into the mix, or CRUDdifying every operation. It's the verb part that I really don't get. That, and the general level of excitement surrounding REST. Why are there so damn many articles like this one?