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

111–118 of 118 posts

Re: REST Anti-Patterns (2008)

#111

Post by icebraining »

haburka wrote: post #106
VonGallifrey wrote: post #70

Earlier quoted context omitted.

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

It's an error code, not a massively distributed system. There's no reason why the solution for the "big four" should be different than for anyone else. Especially since their APIs are designed to be used by everyone else.

Re: REST Anti-Patterns (2008)

#113

Post by chazu »

lloydjatkinson wrote: post #112

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.

One can't really fault REST for the flawed implementations - Fielding's thesis is very explicit about what REST is and isn't.

Just because something becomes an often-misapplied buzzword doesn't say anything negative about the original concept so much as the people mis-implementing it.

Re: REST Anti-Patterns (2008)

#114

Post by virmundi »

sopooneo wrote: post #110
virmundi wrote: post #96

Earlier quoted context omitted.

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.

I know that's what people think. But a JWT in a cookie doesn't strike me as worse than basic auth.

Re: REST Anti-Patterns (2008)

#115

Post by virmundi »

sopooneo wrote: post #110
virmundi wrote: post #96

Earlier quoted context omitted.

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.

I know that's what people think. But a JWT in a cookie doesn't strike me as worse than basic auth.

Re: REST Anti-Patterns (2008)

#116

Post by jack9 »

strictnein wrote: post #55
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.

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

> client was received, understood, accepted, and processed successfully

How is this not processed successfully? The request was processed successfully by the webserver ... and the error was handled by the application, so you can reliably say it was processed successfully at that level, down to the CPU. Narrow interpretation to fit a narrative has no technical merit. That being said, standards are set with certain models in mind and are imperfect almost uniformly, so I don't put too much stock in adherence to what someone imagined or put through committee at some point. I do try to find the best way to iterate reliably with least astonishing abstractions and predictable interfaces. I reason about it in the terms of the standard and it serves my teams.

Re: REST Anti-Patterns (2008)

#117

Post by jack9 »

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.

> I guess

They made a choice to treat multiple applications as one. That's not what I would prefer and is less useful in my opinion. There are some CDNs and payment processors that are in operation, that use the 200 error response, so I tried it. I think it's clearly superior. YMMV

Re: REST Anti-Patterns (2008)

#118

Post by dragonwriter »

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.

> Web server error codes are for web server failures and application level errors are communicated via a 200, properly.

No, expressly in the HTTP spec, 5xx error codes are server errors. 4xx codes are all different kinds of application-level (usually resource-specific) errors.

2xx codes are full-stack success codes.

Post reply on HN