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

81–90 of 118 posts

Re: REST Anti-Patterns (2008)

#81

Post by naasking »

michaelchisari wrote: post #56
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.

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…

That's incorrect. REST has no such restrictions on URLs. URLs can be completely random numbers with no human-discernible meaning.

REST is about architecture, about where state should live, how long it should live, how messages between entities should designate resources/state, all so you can preserve encapsulation and maximal flexibility for service upgrade. Your service is not RESTful if you don't meet these criteria.

RPC has no such restrictions, which means you're free to do everything wrong, which virtually everyone does, and you'll still be doing RPC correctly.

Re: REST Anti-Patterns (2008)

#82

Post by naasking »

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…

> If your API will never be navigated by a human operating a browser, a lot of the REST specification is inapplicable (navigation links, etc.)

That's incorrect. REST was designed for services of all kinds, not just human interfacing services.

The point of links is to support service upgrade via good old encapsulation. Consumers of your API shouldn't just guess links like is commonly trumpeted as REST, they should navigate to the part of your service they need from a well-defined endpoint, and this navigation path has a well-defined lifetime specified by cache control headers (HATEOAS).

The service promises to honour the lifetime of any visited URL on that path as specified by said headers, and any client trying to use that path after the expiry date must be prepared to possibly receive error codes.

Re: REST Anti-Patterns (2008)

#83

Post by naasking »

boubiyeah wrote: post #68
throwaway55523 wrote: post #67

Earlier quoted context omitted.

People need both. REST works well for CRUD operations that don't have complex side effects or constraints. What's often missing in this is intent. I just want to do "the thing" to this particular account or whatever. Personally I like to very selectively add RPC actions on top of the base resource. Tacking an RPC action onto the resource URI allows you to encapsulate the intent of the user's action, handle all the up…

I almost always have both. I tend to use event sourcing and the intent is mandatory. There might be 20 reasons to modify one resource, each with its own list of side effects to later perform. So it's usually POST resource/:id/action and that's fine.

> So it's usually POST resource/:id/action and that's fine.

There's nothing wrong with that. It's not anti-REST or anything, assuming you satisfy the other REST constraints, ie. each request is self-contained and any stateful resources are designated by URLs.

As an aside, I'm personally not a huge fan of human-readable URLs because it encourages API consumers to rely on/construct URLs client-side, which is not REST.

Re: REST Anti-Patterns (2008)

#84

Post by naasking »

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…

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

Nothing inherently wrong with that, but it depends on the situation.

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

That's bad.

Re: REST Anti-Patterns (2008)

#85

Post by smt88 »

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.

Don't write an API. Use something like reindex.io.

Re: REST Anti-Patterns (2008)

#86

Post by sopooneo »

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.

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

To be fully compliant you have to do use something like HTTP Basic Auth, where you resend the username and password with each request.

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.

Re: REST Anti-Patterns (2008)

#87

Post by BoorishBears »

infogulch wrote: post #30
niftich wrote: post #18

Earlier quoted context omitted.

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…

It helps that GraphQL has an actual spec, protocol, and defined schema and is intended to be shipped as a separate microservice that just implements your schema according to the spec. REST is more "hodge podge of concepts" that you can hack on and pollute and misunderstand at will. I guess nothing will stop people from making Frankenstein schemas or poorly performing resolvers but at least the consumption is mostly u…

Some people would rather take a hodge lodge of concepts over a hodge podge of implementations. HTTP clients have been done to death, GraphQL clients on the other hand...

Re: REST Anti-Patterns (2008)

#88

Post by X-Cubed »

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.

Microsoft Silverlight (RIP) only exposed 200 and 404 status codes to the application when using the browser's HTTP stack, presumably due to some API limitation somewhere along the line.

See the Remarks section: https://msdn.microsoft.com/en-us/library/system.net.httpstat...

Other client plugins may have similar issues.

Re: REST Anti-Patterns (2008)

#89

Post by MichaelGG »

mattmanser wrote: post #75
JimDabell wrote: post #54

Earlier quoted context omitted.

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.

I started programming professionaly in 2005 and I can assure you that back then, outside of the browsers, people really didn't know or understand response codes. There's a load of early, popular, Stack Overflow questions that revolve around what status to return when, and how to actually return those codes in your language. For example, in ASP.Net/IIS it was actually quite hard to stop IIS 6 (?) from swallowing your…

I think IIS7's 5xx idiocy was more driven by misguided security concerns. Same as HTTP.sys requiring you to get permission to listen on a port versus not needing any permission if you just open a socket. Or same reason telnet.exe doesn't get installed by default.

Re: REST Anti-Patterns (2008)

#90

Post by developer2 »

emeraldd wrote: post #5
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…

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.

When people mention RPC in this context, are they talking about a generic concept, or are they referring specifically to SOAP? Because SOAP was always a complex mess, pretending that WSDL files somehow added semantic meaning to data, when it fact it was just a serialization format with excessively verbose data typing and validation of element presence/counts. SOAP made even the smallest projects feel like a bloated nightmare typical of "Enterprise bureaucracy". SOAP is the very reason why people eagerly latched onto JSON and REST the moment it became viable.
Post reply on HN