Here's some other thinking about the cost of APIs (discussed earlier on HN) http://writings.quilt.org/2014/05/12/distributed-systems-and...
When REST Gets Messy
21–30 of 48 posts
Re: When REST Gets Messy
#22Earlier quoted context omitted.
> For example, what if a single PUT request creates multiple sub-objects? If a PUT, POST, or PATCH does that, then it does that. So what? > How does my server reply with multiple location headers? It doesn't respond with multiple location headers . With PUT or POST, with an 201 Created status response with the Location: header containing the URI of the parent object (the resource directly created by the PUT/POST), an…
> I'd argue that in REST it would be desirable that resource representations do do that (provide [...] the direct locations of any embedded subentities that are separate addressable). You could actually go a step further - if you're using "Hypertext as the engine of application state" (HATEOAS), URIs for the locations of direct subentities need to be there, if the client is expected to be able to make those state tra…
> You could actually go a step further - if you're using "Hypertext as the engine of application state" (HATEOAS), URIs for the locations of direct subentities need to be there, if the client is expected to be able to make those state transitions, for the API to be "fully RESTful".
Sure, I'd agree with that.
> Though, I'd personally agree with the article that features like discoverability and content negotiation are secondary to those you get from idempotence/properly using HTTP methods, and feel they should be considered bonus features, rather than strict requirements)
I think properly using HTTP is sufficient for calling something an HTTP API, but HATEOAS is necessary for calling it (accurately, at least) a REST API.
There's too much "REST is a popular idea, so lets call out API REST even we think is good for our use case, even if its not REST".
All APIs don't need to be REST APIs, but APIs that call themselves REST APIs should actually be REST APIs, and not just HTTP APIs.
Re: When REST Gets Messy
#23Thinking about this: By merging children into the parent resource, he traded a reduction of requests with the loss of separation of concerns. How about adding a layer instead whose only concern is the reduction of the number of requests for the client. It would collect and merge the info from parent and children resources and return it in merged form to the client ?
An orchestration layer is found in most enterprise architectures
Re: When REST Gets Messy
#24I 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 different framework (like RPC), he could have gotten that to work too, and perhaps would be feeling the "RPC enlightenment" because all of these problems can be solved within RPC too.
No one is arguing that HTTP-based APIs can only do CRUD. You can tunnel basically anything over HTTP, because ultimately the payload is just bytes. But the question is what using HTTP (and/or REST) has actually bought you, compared to competing approaches.
Graydon Hoare (one of the original authors of Rust) wrote an essay about this a while ago that I really love. Unfortunately he took it off the net, but it's still available on the wayback machine: http://web.archive.org/web/20040308200432/http://www.venge.n...
The essay is written in a very whimsical and wandering style, but the point is dead on:
If you want to store or transmit a message, you can do
cryptography, steganography, normalized database tables,
huffman codes, elliptic curves, web pages, morse code,
semaphores, java bytecode, bit-mapped images, wavelet
coefficients, s-expressions, basically anything you can
possibly dream up which codes for some bits. In all cases,
if you're coding bits and you are using a lossless system,
the *only* thing which matters is how *convenient* the encoding
is. There's nothing which makes one encoding "do it better"
than any other, aside from various external measurements of
convenience such as size, speed of encoding, speed of
decoding, hand-editability, self-consistency, commonality,
etc.
Clearly there are benefits to REST/HTTP (being able to use a web browser as an ad-hoc UI in many cases is one), but the idea of "enlightenment" should not be a substitute for an actual compare/contrast of approaches.
So yes, of course the author could find a solution to his problems that still used HTTP. The question is: once he does this, is he better off than if he had chosen a competing technology? (imagining a world where you aren't effectively forced to use HTTP to make it through firewalls).
Re: When REST Gets Messy
#25I 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…
I used be a REST evangelist like that b̶u̶t̶ ̶t̶h̶e̶n̶ ̶I̶ ̶t̶o̶o̶k̶ ̶a̶n̶ ̶a̶r̶r̶o̶w̶ ̶t̶o̶ ̶t̶h̶e̶ ̶k̶n̶e̶e̶.
Now I prefer to simply do RPC over HTTP with a JSON payload.
Re: When REST Gets Messy
#26I 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.
Re: When REST Gets Messy
#27I 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…
I used be a REST evangelist like that b̶u̶t̶ ̶t̶h̶e̶n̶ ̶I̶ ̶t̶o̶o̶k̶ ̶a̶n̶ ̶a̶r̶r̶o̶w̶ ̶t̶o̶ ̶t̶h̶e̶ ̶k̶n̶e̶e̶. Now I prefer to simply do RPC over HTTP with a JSON payload.
[deleted]
Re: When REST Gets Messy
#28Earlier quoted context omitted.
Zapier co-founder here, thanks for pointing this out! We do have a feed ( https://zapier.com/engineering/feeds/latest/ ) but we I think we need to add a meta tag for NewsBlur/readers to pick up on it. We'll do this! We use CSRF protection across all POSTs/PUTs, so cookies are generally required. I'll look into removing this for certain forms (like blog subscribe, fairly safe me thinks!). Thanks again!
Thanks for being responsive! Now that you point it out I realize I could have just clicked on the shuttlecock icon, whoops. I'm not certain what could have caused the cookie problem, since I've just gotten that same error message on a different device, neither of which actually have cookies turned off. (For instance, my HN cookies seem to be working fine...)
Yeah, I'm not sure either. I'll look into it.
Re: When REST Gets Messy
#29I 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…
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 intent and result, and all the other header info that allows those tools to do their thing.
HTTPs ubiquity, for better or worse, makes it about the only option for any web based tool where control from end-to-end isn't a practical option. Better protocols can be made, better hardware and software can be made to utilize them, and some have, but their reach is very limited for now. Understanding the thing we're stuck with is pretty important. Luckily, countless man hours have gone into studying the protocol and building the tools that take advantage of it. Much of that information has been shared openly. I think that's a pretty big advantage over anything else.
Re: When REST Gets Messy
#30Thinking about this: By merging children into the parent resource, he traded a reduction of requests with the loss of separation of concerns. How about adding a layer instead whose only concern is the reduction of the number of requests for the client. It would collect and merge the info from parent and children resources and return it in merged form to the client ?
For those interested in this issue, check out JSON API's compound documents [0], and how to specify inclusion [1]. [0] http://jsonapi.org/format/#document-structure-compound-docum... [1] http://jsonapi.org/format/#fetching-includes
jsonapi looks interesting, but it's really too bad that they require HTTP. If they would change it to be more transport agnostic, it would work really well with websockets.