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

11–20 of 118 posts

Re: REST Anti-Patterns (2008)

#11

Post by ferentchak »

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.

You can blame old browsers for this. In the old days if you returned a non 200 the browser could die in all sorts of interesting ways. Heaven forbid if you try and use any verb other than GET or PUSH, it probably turns the fan off your computer to try and start a fire or something.

Re: REST Anti-Patterns (2008)

#12

Post by TYPE_FASTER »

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…

A combination of REST and Web Sockets works pretty well.

Re: REST Anti-Patterns (2008)

#13

Post by sratner »

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.

Some of the fault for this lies with client libraries. Many, including popular ones[1], either don't provide a way to get the body of error responses at all, or make it particularly cumbersome to do so. For example, success bodies might be parsed automatically by registering the right parser for the content type, but to parse an error response you need to manually instantiate a parser and deserialise the body. Until error responses are first-class objects in client http libraries, devs will continue being lazy.

[1] Not to pick on retrofit -- it is generally awesome -- but http://square.github.io/retrofit/2.x/retrofit/retrofit2/Resp...

Re: REST Anti-Patterns (2008)

#14

Post by mhluongo »

ferentchak wrote: post #11
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.

You can blame old browsers for this. In the old days if you returned a non 200 the browser could die in all sorts of interesting ways. Heaven forbid if you try and use any verb other than GET or PUSH, it probably turns the fan off your computer to try and start a fire or something.

Do you mean POST?

Also, these days, I think the blame is more likely lazy devs, poorly complying frameworks, or compromises to make things easier for some frontend library.

Re: REST Anti-Patterns (2008)

#15

Post by rhizome »

marichards wrote: post #10

Missing anti pattern: consider URLs insecure, especially if for a web browser. Don't include customer details (name, email, account number, etc) or search queries (free text) unless you have determined the security settings on your logging, audit, proxies, .., all conform to data protection requirements that suggest they should be encrypted and only visible to necessary staff. If you expect pages to be bookmarked or…

data protection requirements...

Link?

Re: REST Anti-Patterns (2008)

#16

Post by blowski »

rhizome wrote: post #15
marichards wrote: post #10

Missing anti pattern: consider URLs insecure, especially if for a web browser. Don't include customer details (name, email, account number, etc) or search queries (free text) unless you have determined the security settings on your logging, audit, proxies, .., all conform to data protection requirements that suggest they should be encrypted and only visible to necessary staff. If you expect pages to be bookmarked or…

data protection requirements... Link?

PCI DSS is a related example. You can't store credit card data in your logs.

Re: REST Anti-Patterns (2008)

#17

Post by favorited »

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.

Re: REST Anti-Patterns (2008)

#18

Post by niftich »

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 was replacing schema'd XML documents as the preferred way of over-web information interchange. For consumers, schemaless JSON snippets were attractive for partial processing; for developers, they were attractive for rapid iteration. For makers of "Web 2.0 Mashups", JSON-returning APIs were attractive because processing XML with circa-2006 "cross-browser" nightmare-mode Javascript was about as pleasurable as pulling teeth.

People saw these APIs being called REST, they tried to understand REST, got overwhelmed halfway through, called it REST-like or RESTful instead, and that's how we arrived at where we are.

During this time, RPC wasn't cool or buzzword-compliant, so the people who still RPC did it for good reasons and didn't really blog about it. The quip to consider RPC is nonetheless valid; stuff like gRPC or Thrift are at least proper RPC frameworks, and a much better idea than someone trying to ducktape something with GET and POST for the millionth time.

Luckily, soon, GraphQL will be the newest entrant in this space, and will have to contend an influx of superficially-informed people enticed by its promise. It may have a better track record than REST, because a partial implementation of GraphQL will better resemble GraphQL than a partial implementation of REST will resemble REST.

Re: REST Anti-Patterns (2008)

#19

Post by ben_jones »

Scarbutt wrote: post #7
emeraldd wrote: post #5

Earlier quoted context omitted.

There's nothing really wrong with RPC in my book, just don't call it REST when it's not. I'd say the bigger issue is that a large number of people implement an RPC variant and call it REST because it's on HTTP and not SOAPy.

Is RPC just ad hoc endpoints? The info on REST is overwhelming, to many different opinions, for a simple SPA do programmers really need a formalized client-server contract? Can one just access server capabilities through ad hoc endpoints and write custom code to fetch the data they need? servers define procedures, and they return data. I ask because I'm going to start writing my first http api for a small SPA.

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

Re: REST Anti-Patterns (2008)

#20

Post by yeukhon »

My #1 complaint is there is no OOP client available from service provider. i.e. building a driver to consume the response and turn that into your client code. The irony is I often write my own harness for REST service, and those are generally object-oriented, because I don't want to speak HTTP over and over. Basically I built my a client while writing test, but I need to write test to assert my client which was developed to help writing my test.
Post reply on HN