> Ignoring status codes<p>My favorite is when everything returns a 200, but the response is something like:<p><pre><code> {
status: "fail",
error: "forbidden"
}
</code></pre>
Sometimes they even include the 403 in the response, almost like the developer is giving you a giant middle finger.
The problem is that people want an RPC mechanism, and REST gives them a document transfer mechanism.<p>If your API will never be navigated by a human operating a browser, a lot of the REST specification is inapplicable (navigation links, etc.)<p>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 fit your needs.
The biggest anti-pattern of all: marketing your API as RESTful, when it is really more RPC-like.<p>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.
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.
I believe REST as Fielding defined it has some great benefits. But I'm not a purist. And actually, neither is the person who wrote this post. Because no matter how much the disciples try to wriggle there way around it, using cookies for sessions is not allowed.<p>"We next add a constraint to the client-server interaction: communication must be stateless in nature, as in the client-stateless-server (CSS) style of Section 3.4.3 (Figure 5-3), such that each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server.Session state is therefore kept entirely on the client." - from Fieldings dissertation.<p>To be fully compliant you have to do use something like HTTP Basic Auth, where you resend the username and password with each request.<p>I think you should use cookies to store a token that the server can then use to determine whether the "context" of the request is "logged in" or not. I do it. But it's technically a violation.
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 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.
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.
Anti-pattern #1: Using REST. It's just cargo cult along with everyone describing it and then implementing it differently. The only good part it has is how to layout the URL, and even then it's just common sense.
seriously i dont really care whether an api is restful or restish. at the end of the day its all the same to me. just give me an api endpoint, request and response objects nicely documented and i am golden.
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?<p>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?<p>If you find yourself using a lot of these anti-patterns, maybe you should consider switching to something a little less "REST-ful".
Same title, different article from a few months ago: <a href="https://news.ycombinator.com/item?id=12479370" rel="nofollow">https://news.ycombinator.com/item?id=12479370</a>.