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

31–40 of 118 posts

Re: REST Anti-Patterns (2008)

#31

Post by boubiyeah »

fenwick67 wrote: post #23
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.

omg I saw this once. The status code was 200 but the HTTP body was literally "403: Forbidden". On an endpoint that was supposed to return XML . I guess they just read the spec and assumed "the API returns a '403: Forbidden' " meant this.

All my clients do that. They literally think that REST means "JSON over HTTP" and don't bother with anything else :(

Re: REST Anti-Patterns (2008)

#32

Post by coldtea »

yeukhon wrote: post #22
favorited wrote: post #17

Earlier quoted context omitted.

Because the concept of REST was specifically designed around HTTP, not to be some abstract interface between any 2 systems.

I agree but also have counter example, perhaps not yet as an interface for two systems. But let's start with this: What if I can ask my OS to do things I normally do over some protocol like HTTP in a RESTful style? Create user, list directory, find the last login, tell me linux kernel version. ^ has been done as a separate monitoring tool like Osquery, but can't we make such protocol natively? I don't want to parse m…

>What if I can ask my OS to do things I normally do over some protocol like HTTP in a RESTful style? Create user, list directory, find the last login, tell me linux kernel version.

The /proc filesystem is somewhat close to that when it comes to GET.

>I don't want to parse my command-line output if I can just speak in one human-readble, machine-friendly dialect

That's not what REST (the original concept) is about.

Re: REST Anti-Patterns (2008)

#33

Post by daliwali »

favorited wrote: post #17
dicroce wrote: post #8

If API's are best represented via REST, then why aren't software API's in general RESTful (e.g. I dont POST triangles to my GPU)? The answer: SOME API's are best represented with REST, but most are not.

Because the concept of REST was specifically designed around HTTP, not to be some abstract interface between any 2 systems.

REST actually has nothing to do with HTTP. It happens to map nicely to HTTP, but what it really is, is a set of architectural constraints.

Re: REST Anti-Patterns (2008)

#34

Post by daliwali »

The biggest anti-pattern of all: marketing your API as RESTful, when it is really more RPC-like.

I agree on all points of this article. The only nitpick I have is that tunneling through GET/POST is strictly necessary for HTML forms, since they do not support other verbs.

Re: REST Anti-Patterns (2008)

#36

Post by boubiyeah »

coldtea wrote: post #29
xg15 wrote: post #9

Earlier quoted context omitted.

HTTP != REST though, as the article notes. There are other ways to use port 80/443 that neither violate HTTP nor go full REST - websocket being an (extreme) example. Even the HTTP monopoly is changing. There are lots of new protocols (HTTP2, QUIC, WebRTC) that work besides firewalls and things like ALPN gives a standardized way to tunnel new protocols over an encrypted connection.

> HTTP != REST though, as the article notes. The article might note it, and Roy might insist on it, but nobody cares. For all intents and purposes, what people call REST in practical use is RPC over HTTP with JSON responses.

But then these people are just very wrong. No point encouraging them either :)

Re: REST Anti-Patterns (2008)

#37

Post by SomeStupidPoint »

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.

Wait...

You gotten a response that's HTTP 200, but the JSON itself contained something like "code: 403"?

Well, now I know what I'm going to do if I ever really hate my coworkers/company.

Re: REST Anti-Patterns (2008)

#38

Post by boubiyeah »

SomeStupidPoint wrote: post #37
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.

Wait... You gotten a response that's HTTP 200, but the JSON itself contained something like "code: 403"? Well, now I know what I'm going to do if I ever really hate my coworkers/company.

I've seen that, and also status = 500 with the body { ok: false, status: 404 }

Re: REST Anti-Patterns (2008)

#39

Post by maxxxxx »

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…

Totally agree. REST is a good idea for some use cases but now people want to force it into everything.

But this seems to be the case for a lot web stuff.

Re: REST Anti-Patterns (2008)

#40

Post by maxxxxx »

niftich wrote: post #18
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…

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…

"Most things on the web are half-assed,"

That's my impression too.

Post reply on HN