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

51–60 of 118 posts

Re: REST Anti-Patterns (2008)

#51

Post by foobarrio »

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.

Re: REST Anti-Patterns (2008)

#52

Post by strictnein »

dustingetz wrote: post #48
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.

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…

I've seen plenty of this is in code written in the past 5 years, some within the last year or two.

Re: REST Anti-Patterns (2008)

#53

Post by kbutler »

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 fit your needs.

Re: REST Anti-Patterns (2008)

#54

Post by JimDabell »

dustingetz wrote: post #48
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.

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.

Re: REST Anti-Patterns (2008)

#55

Post by strictnein »

jack9 wrote: post #41
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.

That leads to cleaner code for the frontend frameworks, better interoperability and simpler debugging. Web server error codes are for web server failures and application level errors are communicated via a 200, properly. I run in to this all the time and once we adopted it (for all our APIs), life has been better for customers and our internal teams.

> "application level errors are communicated via a 200, properly"

Wiki:

   2xx Success
   This class of status codes indicates the action requested by the client was received, 
   understood, accepted, and processed successfully
RFC 2616:

   10.2.1 200 OK
   The request has succeeded
Not really "proper" to use it that way, but if it works for you and your users I guess go for it. Also, I highly disagree with the rest of it (cleaner code, better interoperability, simpler debugging), but those are matters of opinion so there's no point in arguing them.

Re: REST Anti-Patterns (2008)

#56

Post by michaelchisari »

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.

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

This doesn't cover 100% of every situation, but it's useful as a quick mnemonic.

Re: REST Anti-Patterns (2008)

#57

Post by michaelchisari »

ben_jones wrote: post #19
Scarbutt wrote: post #7

Earlier quoted context omitted.

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

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.

Re: REST Anti-Patterns (2008)

#58

Post by wtbob »

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…

Another problem is that people want an RPC mechanism, when what they need is a state-transfer mechanism.

It turns out that the semantics of RPC — attractive as they undeniably are — are pretty poor for building real-world distributed systems, while those of REST as a pretty good (or at least better) fit.

Re: REST Anti-Patterns (2008)

#59

Post by LgWoodenBadger »

Sohcahtoa82 wrote: post #26
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…

> consider URLs insecure, especially if for a web browser. A web site I used recently puts your session ID in the URL. If you log in, then alter the URL to remove the session ID, you appear logged out. It gets even worse. Clicking the "Log out" button on the page simply removes the session ID from the URL. If you go back and reload the web page with the session ID in it again, you still appear logged in. The page als…

This is common in servlet-container-land (Java) for handling browsers that don't support cookies. The URLs are rewritten to include the session-identifier (usually a cookie) as a request parameter instead.

There's no other mechanism to associate an HTTP request with back-end state (logged-in/out, etc.) except for session identifiers transmitted by the client browser (through cookies, headers, request parameters).

Re: REST Anti-Patterns (2008)

#60

Post by JustSomeNobody »

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.

Who on Earth is using a browser so old that this might actually happen?
Post reply on HN