REST Anti-Patterns (2008)
infoq.com
REST Anti-Patterns (2008)
1–10 of 118 posts
Re: REST Anti-Patterns (2008)
#2Have 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 flexible than trying to cram your functionality into GET, POST, PUT, PATCH, or DELETE?
If you find yourself using a lot of these anti-patterns, maybe you should consider switching to something a little less "REST-ful".
Re: REST Anti-Patterns (2008)
#3Have 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…
Much as I would like to agree with you, that war was already fought and lost in the early '00s. Port 80/443 were the two ports that couldn't ever be firewalled because web browsing depended on them, so everybody rushed to cram their RPC requests into some kind of HTTP-based protocol.
Re: REST Anti-Patterns (2008)
#4 > Ignoring status codes
My favorite is when everything returns a 200, but the response is something like:
{
status: "fail",
error: "forbidden"
}
Re: REST Anti-Patterns (2008)
#5Have 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…
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.
Re: REST Anti-Patterns (2008)
#6Have 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…
For a public facing interface, I haven't really found REST to be lacking. Adherence to REST buys you simplicity and (if kept to the standards) some implicit understandability.
That said, REST is not the right fit for _every_ use case. The same simplicity mentioned as a strength also limits its flexibility. I think this is no more abundantly clear than microservice oriented architectures. More and more these architectures are moving towards different patterns/protocols for various reasons (gRPC comes to mind).
Re: REST Anti-Patterns (2008)
#7Have 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…
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.
Re: REST Anti-Patterns (2008)
#8If 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.
Re: REST Anti-Patterns (2008)
#9Have 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…
Much as I would like to agree with you, that war was already fought and lost in the early '00s. Port 80/443 were the two ports that couldn't ever be firewalled because web browsing depended on them, so everybody rushed to cram their RPC requests into some kind of HTTP-based protocol.
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.
Re: REST Anti-Patterns (2008)
#10Missing 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 shared, then consider the security impact of where they are stored on local machines too, including in caches if your company is silly enough not to enforce disk encryption for all users.