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

91–100 of 118 posts

Re: REST Anti-Patterns (2008)

#91

Post by paulddraper »

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…

> What ever happened to plain old RPC?

IDK. Whatever happened to plain old REST HTTP?

Re: REST Anti-Patterns (2008)

#92

Post by shados »

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.

And that's the issue. Most engineers don't understand HTTP. Just the amount of people who confuse PUT and POST is pretty high. Getting people to remember that media type exists is hard. Add in the rest, it's just not happening.

But the unicorn "properly designed REST api" is quite nice.

Since i can't trust anyone to do it right though, I'll just use GraphQL because its easier to get people to do right.

Re: REST Anti-Patterns (2008)

#93

Post by shados »

boubiyeah wrote: post #36
coldtea wrote: post #29

Earlier quoted context omitted.

> HTTP != REST though, as the article notes. The article might note it, and Roy might insist on it, but nobody cares. For all intents and purposes, what people call REST in practical use is RPC over HTTP with JSON responses.

But then these people are just very wrong. No point encouraging them either :)

The entire industry is just people who are very wrong hitting critical mass until no one remembers what was right.

Re: REST Anti-Patterns (2008)

#94

Post by [deleted] »

yeukhon wrote: post #43
coldtea wrote: post #32

Earlier quoted context omitted.

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

[deleted]

Re: REST Anti-Patterns (2008)

#95

Post by jaequery »

seriously i dont really care whether an api is restful or restish. at the end of the day its all the same to me. just give me an api endpoint, request and response objects nicely documented and i am golden.

Re: REST Anti-Patterns (2008)

#96

Post by virmundi »

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

Re: REST Anti-Patterns (2008)

#97

Post by deathanatos »

daliwali wrote: post #34

The biggest anti-pattern of all: marketing your API as RESTful, when it is really more RPC-like. I agree on all points of this article. The only nitpick I have is that tunneling through GET/POST is strictly necessary for HTML forms, since they do not support other verbs.

> The only nitpick I have is that tunneling through GET/POST is strictly necessary for HTML forms, since they do not support other verbs.

Only if you ignore AJAX in its entirety. Yes, the browser's capabilities are limited, as it must be a common denominator and can't describe every situation, and thus, can only GET/POST in certain forms.

Re: REST Anti-Patterns (2008)

#98

Post by [deleted] »

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…

[deleted]

Re: REST Anti-Patterns (2008)

#99

Post by JimDabell »

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 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 understood by developers, but they were actually in non-developer's lexicons as well. If you asked the typical geek back then what a 404 was, chances are they'd be able to tell you that it meant something was missing. So I don't agree with you that they were understood by "few people outside of a small community" at all. Using status codes has been standard practice for decades. Maybe it took a couple of years at the beginning of your career for you to notice them, but there simply wasn't this time period of decades when they weren't in use until REST came along.

Re: REST Anti-Patterns (2008)

#100

Post by JimDabell »

dustingetz wrote: post #77
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.

yeah but there are bits in the ~2000 era backend request pipeline that don't understand anything but 200 or do weird things, embedding response code in 200 body lets us tunnel through whatever weird legacy shit

> there are bits in the ~2000 era backend request pipeline that don't understand anything but 200

There's badly written buggy software from any time period doing all sorts of crazy shit, but only accepting 200 certainly wasn't the norm, or even commonplace back then.

Post reply on HN