When REST Gets Messy

Post by [deleted] » Fri, Jul 11, 2014, 5:03 AM UTC

jasonkostempski wrote: post #29

haberman wrote: post #24

Earlier quoted context omitted.

In my opinion, thinking like this how our industry goes down blind corners. To me this is how we wasted 10 years trying to XML-ify everything. Specifically, your arguments rest on the vague and indefinable quality of "enlightenment." I think that this use of "enlightenment" means something along the lines of "I got something to work within a thought framework that appeals to me." But if he had started with a differen…

So much specialized hardware and software has been designed to take advantage of the protocol. REST is really just an architectural guide for using HTTP as it was intended so that those tools can, ideally, provide some efficiency. The entity being transferred isn't really what matters. It's the metadata included about the entity, it's related resources, the client and server capabilities, the explicit expression of i…

Post by icebraining » Fri, Jul 11, 2014, 5:15 AM UTC

haberman wrote: post #24

psadauskas wrote: post #8

I don't think this is messy, this is exactly how REST is intended to work, and is beautiful. I think the most common misconception that REST is simply a way to do CRUD over HTTP, when in fact they are completely orthogonal. You can do CRUD over REST, sure, but REST is also capable of much more. That's the realization the author came to with his `/request` and `/audit` resources, and is the zen of REST. Understanding…

In my opinion, thinking like this how our industry goes down blind corners. To me this is how we wasted 10 years trying to XML-ify everything. Specifically, your arguments rest on the vague and indefinable quality of "enlightenment." I think that this use of "enlightenment" means something along the lines of "I got something to work within a thought framework that appeals to me." But if he had started with a differen…

Post by _pmf_ » Fri, Jul 11, 2014, 7:27 AM UTC

icebraining wrote: post #33

haberman wrote: post #24

Earlier quoted context omitted.

In my opinion, thinking like this how our industry goes down blind corners. To me this is how we wasted 10 years trying to XML-ify everything. Specifically, your arguments rest on the vague and indefinable quality of "enlightenment." I think that this use of "enlightenment" means something along the lines of "I got something to work within a thought framework that appeals to me." But if he had started with a differen…

But if you are trying to argue that REST is better than competing technologies, the question is: what objective benefits does it offer, compared to those other technologies? REST isn't a technology, it's an architectural style. Regarding its benefits, they are all well specified in Fielding's thesis. REST is composed of a few constraints, and abiding by each one gives you certain benefits. That said, I agree with you…

Post by superdude264 » Fri, Jul 11, 2014, 8:15 AM UTC

lomnakkus wrote: post #32

haberman wrote: post #24

Earlier quoted context omitted.

In my opinion, thinking like this how our industry goes down blind corners. To me this is how we wasted 10 years trying to XML-ify everything. Specifically, your arguments rest on the vague and indefinable quality of "enlightenment." I think that this use of "enlightenment" means something along the lines of "I got something to work within a thought framework that appeals to me." But if he had started with a differen…

I think the parent poster should probably have emphasized the importance of HATEOAS more and the power hypertext/linking gives you. I won't spend any time on it in this comment since there are plenty of resources on the web for that, but that's really been the important thing about REST for me. It really is a wonderful thing that clients cannot even attempt invalid state transitions, and I don't think I've seen it do…

Post by itsuart » Fri, Jul 11, 2014, 9:44 AM UTC

icebraining wrote: post #34

itsuart wrote: post #26

I found using HTTP (a mere transport layer) status codes as part of an API very unnatural and wrong. It feels like bending TCP/UDP packets structure to implement FTP to me. And shoehorning your API into any kind of "blessed guidlines" just to earn you a badge? That's just a waste of time.

They're not using HTTP as a mere transport layer, since they're using different HTTP methods and URLs to indicate different semantics. If they were passing payloads through a single endpoint and method, like XML-RPC and SOAP do, that would be using using HTTP as a mere transport layer.