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

REST Anti-Patterns (2008)

infoq.com

Post reply on HN
Print view View original

71–80 of 118 posts

Re: REST Anti-Patterns (2008)

#71

Post by scaryclam »

foobarrio wrote: post #51
strictnein wrote: post #4

> Ignoring status codes My favorite is when everything returns a 200, but the response is something like: { status: "fail", error: "forbidden" } Sometimes they even include the 403 in the response, almost like the developer is giving you a giant middle finger.

I remember reading that ISP's and browsers can do interesting things to non-2xx responses. In that case applications do not even have a chance to handle the error. IIRC Facebook's API does this because they encountered problems with mobile browsers deciding to do weird things with non-2xx responses.

No, this hasn't ever been a thing. This is just stupidity on the side of the developers.

You may be thinking about DNS hijacking by ISPS, but not non-200 issues. There are bound to be some terrible apps out there that respond badly as well, but that's really no excuse.

Re: REST Anti-Patterns (2008)

#72

Post by dustingetz »

kbutler wrote: post #53

The problem is that people want an RPC mechanism, and REST gives them a document transfer mechanism. If your API will never be navigated by a human operating a browser, a lot of the REST specification is inapplicable (navigation links, etc.) So you're throwing out a lot of REST regardless, and the question becomes where to draw the line between ease of implementation and compliance with a standard that doesn't really…

> API will never be navigated by a human operating a browser

But that's what an application is - a human navigating an api

Re: REST Anti-Patterns (2008)

#73

Post by [deleted] »

dragonwriter wrote: post #65
michaelchisari wrote: post #56

Earlier quoted context omitted.

As a shorthand, think of REST as about nouns, and RPC about verbs. /account/1 is REST because the you're looking for an account (noun), the account id is 1, and you're using the HTTP method GET. /search/hello is RPC because it uses a specific verb (search) to call a remote procedure to search for the 'hello' keyword. You're taking an action for which there is no appropriate HTTP method, so RPC can be used instead of…

> /account/1 is REST Probably not. If "what this is and how it relates to other things" is determined by looking at the URL path and not the media type (for "what it is") and link relationshops (for how it relates to other things) it's not REST.

[deleted]

Re: REST Anti-Patterns (2008)

#74

Post by brut »

strictnein wrote: post #4

> Ignoring status codes My favorite is when everything returns a 200, but the response is something like: { status: "fail", error: "forbidden" } Sometimes they even include the 403 in the response, almost like the developer is giving you a giant middle finger.

This is how GCP tells you access to a resource is forbidden. I wrote an Ansible dynamic inventory script and have had to deal with this behaviour.

For example:

Response 403

{'error': {'errors': [{'domain': 'global', 'reason': 'forbidden', 'message': "Required 'compute.instances.list' permission for 'projects/golden-sandbox-162219'"}], 'code': 403, 'message': "Required 'compute.instances.list' permission for 'projects/golden-sandbox-162219'"}}

Re: REST Anti-Patterns (2008)

#75

Post by mattmanser »

JimDabell wrote: post #54
dustingetz wrote: post #48

Earlier quoted context omitted.

A quick glance at history of HTTP can explain this without incompetence. HTTP is fundamental to the world wide web and existed from the beginning in 1989. Fielding's dissertation introduced the idea of REST in 2000. And REST became part of mainstream client libraries in what, 2010? So there's a 20 year period during which code was written against HTTP libraries which were not idiomatic from a REST perspective. Return…

Status codes aren't something introduced by REST, they've been a standard part of HTTP since HTTP 1.0. They've been in widespread use for decades. People use 200 for errors for a few reasons, but it's not because HTTP 0.9 didn't have them.

I started programming professionaly in 2005 and I can assure you that back then, outside of the browsers, people really didn't know or understand response codes.

There's a load of early, popular, Stack Overflow questions that revolve around what status to return when, and how to actually return those codes in your language. For example, in ASP.Net/IIS it was actually quite hard to stop IIS 6 (?) from swallowing your 500 xml response and serving a custom html error page. If I remember correctly some browsers didn't support PUT properly either.

So while you are technically correct, the codes were in use, you are historically wrong, few people outside of a small community understood their use.

I remember this article from the first time around, when people were really getting into REST and there was a fierce debate about strict REST Vs RESTful. In reality RESTful has mainly won and this article was on the wrong side of history.

Re: REST Anti-Patterns (2008)

#76

Post by self-diversity »

mattmanser wrote: post #75
JimDabell wrote: post #54

Earlier quoted context omitted.

Status codes aren't something introduced by REST, they've been a standard part of HTTP since HTTP 1.0. They've been in widespread use for decades. People use 200 for errors for a few reasons, but it's not because HTTP 0.9 didn't have them.

I started programming professionaly in 2005 and I can assure you that back then, outside of the browsers, people really didn't know or understand response codes. There's a load of early, popular, Stack Overflow questions that revolve around what status to return when, and how to actually return those codes in your language. For example, in ASP.Net/IIS it was actually quite hard to stop IIS 6 (?) from swallowing your…

The endpoints in question are not typically used by humans driving a browser, so these objections don't seem applicable.

Re: REST Anti-Patterns (2008)

#77

Post by dustingetz »

JimDabell wrote: post #54
dustingetz wrote: post #48

Earlier quoted context omitted.

A quick glance at history of HTTP can explain this without incompetence. HTTP is fundamental to the world wide web and existed from the beginning in 1989. Fielding's dissertation introduced the idea of REST in 2000. And REST became part of mainstream client libraries in what, 2010? So there's a 20 year period during which code was written against HTTP libraries which were not idiomatic from a REST perspective. Return…

Status codes aren't something introduced by REST, they've been a standard part of HTTP since HTTP 1.0. They've been in widespread use for decades. People use 200 for errors for a few reasons, but it's not because HTTP 0.9 didn't have them.

yeah but there are bits in the ~2000 era backend request pipeline that don't understand anything but 200 or do weird things, embedding response code in 200 body lets us tunnel through whatever weird legacy shit

Re: REST Anti-Patterns (2008)

#78

Post by naasking »

throwaway18917 wrote: post #2

Have we considered that these REST "anti-patterns" exist because REST is fundamentally inappropriate for what most people are trying to use it for? What if you can't shoehorn your functionality into the handful of REST verbs? What if none of the status codes make sense? What ever happened to plain old RPC? Have we stopped to consider that people tunnel things through POST or GET requests because it's easier and more…

> Have we considered that these REST "anti-patterns" exist because REST is fundamentally inappropriate for what most people are trying to use it for?

Or perhaps people actually don't understand REST, but think they do, thus leading to endless blog articles about "REST levels" and other nonsense.

> What if you can't shoehorn your functionality into the handful of REST verbs?

GET and POST can represent any arbitrary program (they map to the lambda calculus after all). You don't need any more than that, in principle. The other verbs are merely optimizations.

> What ever happened to plain old RPC?

The inescapable failure modes of RPC are exactly what REST addresses.

Re: REST Anti-Patterns (2008)

#79

Post by naasking »

coldtea wrote: post #28
niftich wrote: post #18

Earlier quoted context omitted.

Most things on the web are half-assed, and half-assed HTTP APIs enable rapid results (before the problems start). REST is not fundamentally inappropriate, it just needs a lot of careful design about domain objects, link relations, and media types. Generally, people are not very good at thoughtful design. It didn't help that REST began to trend as an idea right around the same time that intentionally schemaless JSON w…

> REST is not fundamentally inappropriate, it just needs a lot of careful design about domain objects, link relations, and media types. Generally, people are not very good at thoughtful design. Especially if it's not worth the effort.

Honestly, this should be a common part of web frameworks by now. It's a travesty that our industry hasn't developed a solid foundation for this kind of thing 16 years after it was published.

The best we've got on this mark is the Waterken server, which is pretty good, but not good enough.

Re: REST Anti-Patterns (2008)

#80

Post by naasking »

michaelchisari wrote: post #57
ben_jones wrote: post #19

Earlier quoted context omitted.

It just causes so much busy work. Then busy work leads to bugs, which leads to framework abstractions, which leads to implicit nuance in almost every part of web development. RPC and client-server contracts, as well as static-typing, is a bloody god send and the whole world will be in a better place once we formalize and accept it (I didn't say standardize I said formalize).

I'll defend REST's utility for simple data retrieval. If I just need a paginated list of comments on a video, being able to quickly hit /video/1093/comments and get that list back is really nice. More complex use cases, and specifically non-idempotent operations, is where I find REST doesn't hold up as well as RPC.

> If I just need a paginated list of comments on a video, being able to quickly hit /video/1093/comments and get that list back is really nice.

REST isn't about human-readable URLs. The link to the comments should have been part of the representation returned for /video/1093 (typically JSON these days, so a "comments" property of the object).

Post reply on HN