emperorpenguin

3 ms·

1. 1.▲
   by 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 CRUDdifyin
2. 2.▲
   by 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 o
3. 3.▲
   by emperorpenguin 15y ago

   Don't confuse ubiquity with quality. Witness: VHS, Paris Hilton.
4. 4.▲
   by 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 con
5. 5.▲
   by emperorpenguin 15y ago

   But how does REST improve scalability, caching, retrys, etc... over ANY other HTTP-request based scheme?
6. 6.▲
   by emperorpenguin 15y ago

   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