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

41–48 of 48 posts

Re: When REST Gets Messy

#41

Post by icebraining »

itsuart wrote: post #39
icebraining wrote: post #34

Earlier quoted context omitted.

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.

Seems I phrased my previous comment too vague, sorry for that. I'm aware of what REST stands for. My question is what advantages utilizing "obscure" HTTP verbs and headers with spreading "endpoints" all over ones application provides compared to RPC over HTTP? Surely, using RPC with a single endpoint is much simpler and thus more maintainable/modifiable?

Which obscure HTTP verbs? I didn't see any in the article.

You should read Fielding's thesis, but the short version is: when you're using a single endpoint, you're not really simplifying the communication -after all, your application still needs to do different things-, you're just replacing parts of the standard HTTP methods and server-sent URLs (which the client doesn't need to know beforehand) with custom/proprietary method names which the client needs to be coded against specifically.

Of course, this depends on whether you're actually following REST or not. If you're hardcoding endpoints all over your client applications, your architecture is not really RESTful.

Still, even if you do hardcode them, you still gain some advantages: for example, you can add a layer of caching by just sticking Varnish in the middle, which is not possible with RPC without custom code. That's the advantage of following the Uniform Interface constraint.

Re: When REST Gets Messy

#42

Post by ldng »

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 ?

How about using "multipart/related" ? Would make sense to me. Although I've never seen that so I guess I must be missing something.

Re: When REST Gets Messy

#43

Post by candu »

superdude264 wrote: post #37
lomnakkus wrote: post #32

Earlier quoted context omitted.

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…

Do you know of any publicly available API that is truly RESTful (has embrace HATEOAS)?

RunKeeper's HealthGraph returns discoverable URIs from /users:

http://developer.runkeeper.com/healthgraph/users

Re: When REST Gets Messy

#44

Post by jmakeig »

REST, as Fielding described it, is good for decoupled systems that can (and need to) evolve independently, like web browsers consuming HTML and JavaScript.

If you can relax the decoupling or independent evolution constraints, RPC over HTTP is usually easier to understand and implement. This is where most HTTP APIs fall. (…and that’s OK)

Re: When REST Gets Messy

#45

Post by dragonwriter »

T-R wrote: post #16
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 chi…

> 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

That seems to be a pretty significant feature of SPDY and the in-progress HTTP/2.0 work.

Re: When REST Gets Messy

#46

Post by T-R »

dragonwriter wrote: post #45
T-R wrote: post #16

Earlier quoted context omitted.

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 chi…

> 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 That seems to be a pretty significant feature of SPDY and the in-progress HTTP/2.0 work.

I wasn't aware of that, that's good to hear. I'm under the impression, though, that since SPDY encrypts everything, that you can't get caching at intermediate nodes unless you explicitly MITM yourself, which would reduce the utility of that feature. Then again, I'm not sure how much caching happens outside of places where you'd MITM yourself now anyway, so I guess in practice, that might not be a huge step back.

Re: When REST Gets Messy

#47

Post by dragonwriter »

T-R wrote: post #46
dragonwriter wrote: post #45

Earlier quoted context omitted.

> 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 That seems to be a pretty significant feature of SPDY and the in-progress HTTP/2.0 work.

I wasn't aware of that, that's good to hear. I'm under the impression, though, that since SPDY encrypts everything , that you can't get caching at intermediate nodes unless you explicitly MITM yourself, which would reduce the utility of that feature. Then again, I'm not sure how much caching happens outside of places where you'd MITM yourself now anyway, so I guess in practice, that might not be a huge step back.

> I wasn't aware of that, that's good to hear. I'm under the impression, though, that since SPDY encrypts everything, that you can't get caching at intermediate nodes unless you explicitly MITM yourself, which would reduce the utility of that feature.

Last I heard, it was quite a matter of debate in the IETF workgroup on HTTP2 the extent to which SPDY's "TLS is mandatory" approach would be adopted for HTTP/2.0 (IIRC, Microsoft at one point staked out a "we will enable HTTP/2.0 without TLS in our browser so the standard better allow it" position, and numerous parties making strong arguments that there were definite use cases -- especially internal networks -- where users would want the other advantages of HTTP/2.0 and where TLS would be a burden rather than a benefit.)

And if you are worried about caching internal to your own organization, you could, in the worst case, use a (TLS-required) HTTP/2.0 user facing server with HTTP/1.1 (non-TLS) internal servers, eliminating the need to MITM your own TLS traffic. Obviously, that doesn't help external cacheability, but you probably aren't going to usually want to send external content insecurely from an app.

Post reply on HN