Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

When REST Gets Messy

zapier.com

Post reply on HN
Print view View original

11–20 of 48 posts

Re: When REST Gets Messy

#11

Post by dragonwriter »

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…

> I think the most common misconception that REST is simply a way to do CRUD over HTTP, when in fact they are completely orthogonal.

I dunno, REST maps to CRUD pretty well -- but its pretty limited when you think of it as restricted to CRUD operations against the equivalent of base tables in whatever your datastore of choice is -- its more like CRUD operations against views with arbitrarily complex rules mapping operations on the views to operations against base tables...

Re: When REST Gets Messy

#12

Post by bryanh »

jessaustin wrote: post #10

Why can't I subscribe to a feed for this blog? I was going to blame NewsBlur, but upon viewing source I don't see link rel s for anything but the favicons and stylesheet. I thought for a moment that I might just give them my email address, but then they pulled a bizarre "Looks like you have cookies disabled" out of some orifice. A: I don't. B: why would you need cookies to post a form?

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!

Re: When REST Gets Messy

#13

Post by psadauskas »

dragonwriter wrote: post #11
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…

> I think the most common misconception that REST is simply a way to do CRUD over HTTP, when in fact they are completely orthogonal. I dunno, REST maps to CRUD pretty well -- but its pretty limited when you think of it as restricted to CRUD operations against the equivalent of base tables in whatever your datastore of choice is -- its more like CRUD operations against views with arbitrarily complex rules mapping oper…

You are correct, I could have clarified it as "CRUD of business objects in a database".

Re: When REST Gets Messy

#14

Post by T-R »

dragonwriter wrote: post #7
leeoniya wrote: post #2

i've been meaning to write something similar about the whole REST craze. REST breaks down pretty rapidly once you get out of the key-value-store paradigm (read: anything involving child objects). REST lacks the ability to relay full state-change semantics without hackery. As the article pointed out, it forces you to be extra chatty over http, which is far from free over the congested, global network that is the inter…

> 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 transitions, for the API to be "fully RESTful". (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)

Re: When REST Gets Messy

#15

Post by jessaustin »

bryanh wrote: post #12
jessaustin wrote: post #10

Why can't I subscribe to a feed for this blog? I was going to blame NewsBlur, but upon viewing source I don't see link rel s for anything but the favicons and stylesheet. I thought for a moment that I might just give them my email address, but then they pulled a bizarre "Looks like you have cookies disabled" out of some orifice. A: I don't. B: why would you need cookies to post a form?

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...)

Re: When REST Gets Messy

#16

Post by T-R »

je42 wrote: post #3

Thinking 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 ?

I really do wish HTTP had a mechanism for responding to a single request with multiple combined response bodies as if requests were made for each individually (from the perspective of, e.g., a caching proxy) - the loss of separation of concerns from merging children into the parent isn't just a usability issue, it also means you lose your cache granularity - the cache for the parent object is now stale whenever a child is modified, and a request for a child after getting the parent won't hit the cache at the request level.

There's keep-alive, but that still means that if you want to get a parent and its children, you have to wait for the parent request round-trip.

To add - this is a major issue we've been working through at Slant.co - we've combined child objects into the requests for the parent objects (sometimes even two levels down), but it's significantly complicated caching efforts - we're in the process of building some namespacing into our server-side request cache, so we can transparently make cached Question and Option pages stale whenever, e.g., the title of a Pro/Con gets changed. If HTTP allowed multiple responses, we could treat everything transparently server-side as individual requests, and get much higher hit-rates for proxy and client-side caches.

Re: When REST Gets Messy

#17

Post by [deleted] »

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…

[deleted]

Re: When REST Gets Messy

#18

Post by 21echoes »

je42 wrote: post #3

Thinking 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 ?

that's what we've done with our API: we have a meta-resource /multi that takes in an ordered array of Request objects, each with a URI, (HTTP)Method, and Parameters. The /multi service then splits these Requests out, sends them off to the "real" server in order (GETs, of course, being parallelizable when next to each other in the provided order), and then composes the responses back into one array of Response objects which gets passed back to the client.

It's honestly amazing to work with, as we can be very strict about our separation of concerns on the backend, while letting the frontend combine bits and pieces as makes sense for a given client interface.

Re: When REST Gets Messy

#19

Post by munro »

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…

It's hard for me to submit to a philosophy for reasons like that it's beautiful, and that you will reach zen. Level 3 enlightenment sounds very cultish to me. :) I've dropped the notion of REST and been very happy with simple RPC, instead of contorting my mental model into resources or to align with the HTTP spec.

I personally have found zen in applying simpler concepts to software development. Such as composition over inheritance to my API design, mixing in certain aspects like content negotiation or caching, when those complexities become necessary. Or separation of concerns, making sure endpoints don't do too much, and the realization of concerns vs technology [1]. Really thinking about the notion of simplicity as describe by Rick Hickley in Simple Made Easy [2]. Or "There are only two hard problems in Computer Science: cache invalidation and naming things"--putting off caching until an endpoint becomes a problem--and not worrying if my URL structure is RESTful.

Here's an example of an API that I find beautiful [3].

[1] https://www.youtube.com/watch?v=x7cQ3mrcKaY [2] http://www.infoq.com/presentations/Simple-Made-Easy [3] https://mandrillapp.com/api/docs/

Re: When REST Gets Messy

#20

Post by kalmar »

je42 wrote: post #3

Thinking 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

Post reply on HN