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

101–110 of 118 posts

Re: REST Anti-Patterns (2008)

#101

Post by mathw »

sopooneo wrote: post #86

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 Sectio…

Cookies could be compliant with that, if they contained the entire session state and weren't a key into the session state on the server.

They probably shouldn't be used like that, but technically it would be compliant with the requirements you've quoted.

Re: REST Anti-Patterns (2008)

#102

Post by mattmanser »

JimDabell wrote: post #99
mattmanser wrote: post #75

Earlier quoted context omitted.

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 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. > So while you are technically correct, the codes were in use, you are historically wrong, few people outside of a small community understood their use. I started in the late 90s, and even back then they were commonly used. They weren't just well understoo…

Given that ajax was only added to browsers in 1999 and AJAX didn't really catch on seriously until 2003/2004ish, what you're claiming is at odds, again, with actual history.

404s are a different matter because you'd get 404 pages, so it's not at all an argument to support your position. It doesn't mean developers understood what to return from an ajax call, or that they understood HTTP verbs.

I'll remind you again that it was actually fairly hard to return the correct codes from a lot of frameworks, so objective facts are at odds with your recollection of events.

I stick by my assertion that the vast majority of web developers in our industry didn't really understand http until the latter half of the 2000s. I also specifically remember presentations to all our developers both junior and senior of how browser caching worked, which to most developers at the time was a bit of a mystery, and the correct headers to return to control it.

Here are some examples from 2008 of developers on SO discussing things which seem obvious today:

http://stackoverflow.com/questions/165779/are-the-put-delete... http://stackoverflow.com/questions/165720/how-to-debug-restf...

Re: REST Anti-Patterns (2008)

#103

Post by JimDabell »

mattmanser wrote: post #102
JimDabell wrote: post #99

Earlier quoted context omitted.

> 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. > So while you are technically correct, the codes were in use, you are historically wrong, few people outside of a small community understood their use. I started in the late 90s, and even back then they were commonly used. They weren't just well understoo…

Given that ajax was only added to browsers in 1999 and AJAX didn't really catch on seriously until 2003/2004ish, what you're claiming is at odds, again, with actual history. 404s are a different matter because you'd get 404 pages, so it's not at all an argument to support your position. It doesn't mean developers understood what to return from an ajax call, or that they understood HTTP verbs. I'll remind you again th…

> Given that ajax was only added to browsers in 1999 and AJAX didn't really catch on seriously until 2003/2004ish, what you're claiming is at odds, again, with actual history.

Ajax is not the only way to access a web service.

> 404s are a different matter because you'd get 404 pages

…which are returned with a status code of 404. That's where the name comes from. Non-200 status codes were ubiquitous even back then.

> It doesn't mean developers understood what to return from an ajax call, or that they understood HTTP verbs.

Ajax is irrelevant and we're talking about status codes, not verbs.

> I'll remind you again that it was actually fairly hard to return the correct codes from a lot of frameworks, so objective facts are at odds with your recollection of events.

Perhaps the technology _you_ were using made it difficult, but it certainly wasn't the general case. PHP, classic ASP, mod\_perl, mod\_python, CGI scripts… they could all respond with non-200 status codes easily. Which ones are you thinking of that made it difficult?

> Here are some examples from 2008 of developers on SO discussing things which seem obvious today:

Come on man, clueless questions get asked about extremely well established things on Stack Overflow every single day. That doesn't mean that those concepts are suddenly no longer well understood, it just means that the person asking is a beginner. And neither of those questions mentioned status codes at all!

Re: REST Anti-Patterns (2008)

#104

Post by wtbob »

naasking wrote: post #83
boubiyeah wrote: post #68

Earlier quoted context omitted.

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.

I think a more properly-REST approach would be to PUT a representation of the resource with the action applied. That is, rather than POSTing to /resources/:id/close, one would PUT a closed version of the resource to /resources/:id.

Re: REST Anti-Patterns (2008)

#105

Post by liveoneggs »

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…

It comes from SOAP, which is supposed to be "protocol independent" so you would return statuses inside of the envelope section of the XML.

Re: REST Anti-Patterns (2008)

#106

Post by haburka »

VonGallifrey wrote: post #70
jack9 wrote: post #41

Earlier quoted context omitted.

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.

> Web server error codes are for web server failures and application level errors are communicated via a 200, properly. I guess google, facebook, microsoft and all the others are doing it wrong then? Or Improperly according to you? Because they do not respond with a 200 on application level errors in their APIs.

The needs and use case for Google, Microsoft, and Facebook are radically different than anyone else. No developer should imitate them blindly because, chances are, the conditions you are working in do not match the big four. There is no ideal way of coding, instead, you match your style to what is needed. I wish more people understood that.

Re: REST Anti-Patterns (2008)

#107

Post by naasking »

wtbob wrote: post #104
naasking wrote: post #83

Earlier quoted context omitted.

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

I think a more properly-REST approach would be to PUT a representation of the resource with the action applied. That is, rather than POSTing to /resources/:id/close, one would PUT a closed version of the resource to /resources/:id.

I don't see why that would be more REST. POST is to be used for side-effecting operations, PUT is an optimization over POST for idempotent effectful operations.

Certainly a PUT solution might have some advantages for replayability in case of network partitions, but REST doesn't this choice dictate one way or the other.

Re: REST Anti-Patterns (2008)

#108

Post by foobarrio »

scaryclam wrote: post #71
foobarrio wrote: post #51

Earlier quoted context omitted.

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.

No, this hasn't ever been a thing. This is just stupidity on the side of the developers. You may be thinking about DNS hijacking by ISPS, but not non-200 issues. There are bound to be some terrible apps out there that respond badly as well, but that's really no excuse.

I am not talking about the app I am talking about the environment the app is running in. Of course there are crappy apps (I've made a bunch of them!) I remember IIS doing funky things with non-200 return codes. 5xx codes would have some default handler. I am certain this was an issue with configuration and a dysfunctional development process. In the shop I was in, in the mid 2000's, we the devs didn't have direct access to the web server and having the IT guys make any update took on the order of weeks. Instead of fixing the IIS config we just returned 2xx and handled the error in the app layer. We also had a couple SOAP(shudder) services that always returned code 200 with error codes in the response XML body. Much of our app code used this pattern for consistency. We also would deploy our services on various other web servers we didn't have full control over so it was just easier to use this pattern.

Re: REST Anti-Patterns (2008)

#109

Post by michaelchisari »

dragonwriter wrote: post #65
michaelchisari wrote: post #56

Earlier quoted context omitted.

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…

> /account/1 is REST Probably not. If "what this is and how it relates to other things" is determined by looking at the URL path and not the media type (for "what it is") and link relationshops (for how it relates to other things) it's not REST.

Reading over your comments, I'm curious what you would consider to be an API that properly implements REST principles according to the original dissertation.

Re: REST Anti-Patterns (2008)

#110

Post by sopooneo »

virmundi wrote: post #96
sopooneo wrote: post #86

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 Sectio…

I question that idea. Cookie is a standard header. So is Authorization. It's up to the server to require either. Basic auth header removes the need for a handshake to negotiate tokens. Authorization: Bearer (token) is now a standard. I suppose Cookie: (token) could be too, but too many people felt dirty. My point is that Cookie does provide the credentials required for the call contex, this fulfilling the self contai…

As I read it, the problem is not the mechanism by which a session is maintained, but the very existence of a session at all.
Post reply on HN