REST Anti-Patterns (2008)

Re:REST Anti-Patterns (2008) by jack9 on Wednesday May 10, 2017 @02:48PM (#14310594)

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.

[ Parent | on HN ]

Re:REST Anti-Patterns (2008) by strictnein on Wednesday May 10, 2017 @03:29PM (#14310916)

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

[ Parent | on HN ]

Re:REST Anti-Patterns (2008) by jack9 on Monday May 15, 2017 @12:24AM (#14339139)

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

[ Parent | on HN ]

Re:REST Anti-Patterns (2008) by dragonwriter on Monday May 15, 2017 @12:42AM (#14339206)

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

[ Parent | on HN ]

Re:REST Anti-Patterns (2008) by VonGallifrey on Wednesday May 10, 2017 @05:10PM (#14311753)

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

[ Parent | on HN ]

Re:REST Anti-Patterns (2008) by jack9 on Monday May 15, 2017 @12:29AM (#14339161)

> 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

[ Parent | on HN ]

Re:REST Anti-Patterns (2008) by haburka on Thursday May 11, 2017 @09:18AM (#14315749)

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.

[ Parent | on HN ]

Re:REST Anti-Patterns (2008) by icebraining on Thursday May 11, 2017 @08:30PM (#14320604)

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.

[ Parent | on HN ]