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

41–50 of 118 posts

Re: REST Anti-Patterns (2008)

#41

Post by jack9 »

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.

Re: REST Anti-Patterns (2008)

#42

Post by maxxxxx »

yeukhon wrote: post #20

My #1 complaint is there is no OOP client available from service provider. i.e. building a driver to consume the response and turn that into your client code. The irony is I often write my own harness for REST service, and those are generally object-oriented, because I don't want to speak HTTP over and over. Basically I built my a client while writing test, but I need to write test to assert my client which was devel…

SOAP works that way. But that has its own set of problems...

Re: REST Anti-Patterns (2008)

#43

Post by yeukhon »

coldtea wrote: post #32
yeukhon wrote: post #22

Earlier quoted context omitted.

I agree but also have counter example, perhaps not yet as an interface for two systems. But let's start with this: What if I can ask my OS to do things I normally do over some protocol like HTTP in a RESTful style? Create user, list directory, find the last login, tell me linux kernel version. ^ has been done as a separate monitoring tool like Osquery, but can't we make such protocol natively? I don't want to parse m…

> What if I can ask my OS to do things I normally do over some protocol like HTTP in a RESTful style? Create user, list directory, find the last login, tell me linux kernel version. The /proc filesystem is somewhat close to that when it comes to GET. > I don't want to parse my command-line output if I can just speak in one human-readble, machine-friendly dialect That's not what REST (the original concept) is about.

I understand REST's original motivation, but having a modern protocol to work with resources on a computer doesn't seem too much to ask.

Re: REST Anti-Patterns (2008)

#45

Post by niftich »

daliwali wrote: post #33
favorited wrote: post #17

Earlier quoted context omitted.

Because the concept of REST was specifically designed around HTTP, not to be some abstract interface between any 2 systems.

REST actually has nothing to do with HTTP. It happens to map nicely to HTTP, but what it really is, is a set of architectural constraints.

The author of REST, Roy Fielding, feels that they're intertwined [1]:

HTTP/1.1 is a specific architecture that, to the extent I succeeded in applying REST-based design, allows people to deploy RESTful network-based applications in a mostly efficient way, within the constraints imposed by legacy implementations. The design principles certainly predated HTTP, most of them were already applied to the HTTP/1.0 family, and I chose which constraints to apply during the pre-proposal process of HTTP/1.1, yet HTTP/1.1 was finished long before I had the available time to write down the entire model in a form that other people could understand. All of my products are developed iteratively, so what you see as a chicken and egg problem is more like a dinosaur-to-chicken evolution than anything so cut and dried as the conceptual form pre-existing the form. HTTP as we know it today is just as dependent on the conceptual notion of REST as the definition of REST is dependent on what I wanted HTTP to be today."

[1] https://web.archive.org/web/20091111012314/http://tech.group...

Re: REST Anti-Patterns (2008)

#46

Post by emeraldd »

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 ben_jones stated, a client and server need a formalized contract or you're doomed to break things. Whatever you use needs to at a minimum be: - internally consistent - sufficiently documented that a developer on either side understands what the other side does

REST is just a set of rules to follow that attempt to avoid some pitfalls and provide a common parlance.

Re: REST Anti-Patterns (2008)

#47

Post by strictnein »

SomeStupidPoint wrote: post #37
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.

Wait... You gotten a response that's HTTP 200, but the JSON itself contained something like "code: 403"? Well, now I know what I'm going to do if I ever really hate my coworkers/company.

The codebase I'm working on currently has that and more.

Re: REST Anti-Patterns (2008)

#48

Post by dustingetz »

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. Returning status codes in the response body is a common workaround for compatibility with code written in this 20 year window.

Re: REST Anti-Patterns (2008)

#49

Post by boubiyeah »

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…

Nor was it even just idiomatic HTTP. Using the proper HTTP status or verbs for instance is not REST, just caring about the HTTP spec.

Re: REST Anti-Patterns (2008)

#50

Post by dustingetz »

boubiyeah wrote: post #49
dustingetz wrote: post #48

Earlier quoted context omitted.

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…

Nor was it even just idiomatic HTTP. Using the proper HTTP status or verbs for instance is not REST, just caring about the HTTP spec.

you're right, a little deeper digging and i learned that in 1989 http only had GET! I dont think verbs came until '96
Post reply on HN