Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

REST Anti-patterns

marcelo-cure.blogspot.com

Post reply on HN
Print view View original

51–60 of 133 posts

Re: REST Anti-patterns

#51

Post by drj077 »

PaulHoule wrote: post #24

This misses the elephant in the room. The REST-inspired API that requires 10,000 API calls to do something that could be done in 1. This is a disaster from a simple performance perspective. There is no simple way to build transactions on top of REST so if you need to do something that involves updating more than one data record you really are best off updating them all in one API call. When you are writing a web fron…

How I've addressed the transaction issue in the past is to expose it specifically as a transaction. For instance, POST /posts/transactions would contain a list of transformations to /posts and will receive a transaction id as a response. The id can be polled for success (/posts/transactions/:uuid) or results can be pushed to a browser. It is more work to be able to roll that back if one fails, but that's a coding issue not so much an API one.

I'd love some feedback on this approach. How do other people allow efficient mass changes?

Re: REST Anti-patterns

#52

Post by drj077 »

PaulHoule wrote: post #24

This misses the elephant in the room. The REST-inspired API that requires 10,000 API calls to do something that could be done in 1. This is a disaster from a simple performance perspective. There is no simple way to build transactions on top of REST so if you need to do something that involves updating more than one data record you really are best off updating them all in one API call. When you are writing a web fron…

How I've addressed the transaction issue in the past is to expose it specifically as a transaction. For instance, POST /posts/transactions would contain a list of transformations to /posts and will receive a transaction id as a response. The id can be polled for success (/posts/transactions/:uuid) or results can be pushed to a browser. It is more work to be able to roll that back if one fails, but that's a coding issue not so much an API one.

I'd love some feedback on this approach. How do other people allow efficient mass changes?

Re: REST Anti-patterns

#54

Post by KillerRAK »

Resource verbs in POST URLs are almost always a bad idea. You POST a command via the body to the resource and should expect a result in turn.

Though I do understand the idea that URLs with verbs allow the API to be self describing via links, I think it's a bit naive (and verbose) to think a user will get all the info they need from hitting the API. RAML and its variants do a great job of conveying this information.

Re: REST Anti-patterns

#55

Post by EugeneOZ »

amk_ wrote: post #53
EugeneOZ wrote: post #48

Earlier quoted context omitted.

Only when it's GET request. This request will not return you any resource information, with id if account or without.

What about DELETE?

DELETE is for deletion only, this request can't have body, so only what we can do is send id in query. When we want to remove multiple resources we either should send multiple requests (what is slow), or combine multiple ids in query (what is ugly and non-idiomatic).

Re: REST Anti-patterns

#56

Post by carsongross »

The initial and fundamental problem is a misapplication of REST. To take advantage of REST, you need some form of hypertext, not raw JSON APIs.

Additionally, on a practical level, you need the end points to be relatively coarse grained, which can be achieved if you design the API for your UI use case, rather than general data access:

http://intercoolerjs.org/2016/01/18/rescuing-rest.html

Shoehorning HATEOS in JSON APIs is a category error:

http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.ht...

Long story short, REST: you are all doing it completely wrong.

Re: REST Anti-patterns

#57

Post by niftich »

The content of the blog post is okay, but the premise is flawed. Most of us have reluctantly accepted the abuse of terminology that happens when everyone calls these APIs 'RESTful' -- but they're not. They're inspired by REST, but cargo-cult took the easiest-to-implement pieces all the while pretending to stand on some moral high-ground about not being openly RPC because 'RESTful is the right way'.

This results in a worst-of-both-worlds situation, where most of these API don't have custom mediatypes that I can Accept: header for, don't have custom link relations one can programmatically traverse, and some poor person had to contort their data model to come up with plausibly 'resourcey' objects to make HTTP calls against, all the while losing simple reassurance you would've gotten from an uncool RPC endpoint.

HATEOAS is critical to REST -- it being nothing more than a terribly obtuse rendition of the ideas behind how the web (but more importantly, the semantic web) works. This isn't the usual rant complaining about how HATEOAS is most implementers' afterthought; this is the rant about how HATEOAS is the entire damn point; without it you're just squirting JSON on the wire and using HTTP as a transport because it doesn't get blocked on a middlebox.

And now that we've retrofitted schemas into JSON, and moved half our APIs to use CORS/CSP-needing PUT/DELETE methods, and require OAuth for more than half of the requests, the original advantages of this scheme are entirely gone -- you can no longer just muck around in some half-baked javascript, parse out a single field, discard the rest and surface it in a 'web 2.0 mashup'. And when the vendor supplies the SDK anyway (even in Javascript), the exact form the messages take on the wire is entirely irrelevant. I hope the new wave of RPC (helped by the bi-directional multiplexing transport protocol inexplicably known as HTTP/2) becomes the new fad and kills this awful fumbling with cargo-cult fake-REST once and for all.

Re: REST Anti-patterns

#58

Post by binarymax »

caseysoftware wrote: post #33
binarymax wrote: post #21

Earlier quoted context omitted.

In CRUD, delete is rarely a hard delete that removes the data entirely. Best practice in most situations is setting a flag to mark it deleted. Closing an account is the same behavior - you are not purging the data, rather setting it to a closed/deleted/archived state.

You're packing a lot of implied behavior - based on your experiences - into the DELETE verb instead of using the dictionary definition. If everyone has experience with similar systems, then you're fine. If others have worked with hard delete systems or aren't native English speakers, you're introducing ambiguity and context that isn't necessarily there.

Using DELETE this way is absolutely not introducing or implying anything, this is best-practice REST. It signifies exactly the behavior I describe.

Re: REST Anti-patterns

#59

Post by simonh »

strictnein wrote: post #23
fzilla wrote: post #16

Other commenters are correct that POST /accounts/4402278/close is not right (and also fairly hilariously contradicted in the next section). Account status (open, closed, suspended, whatever else) is a property of the account, in the same way that the account owner's name is a property of the account. If you went to all the trouble to represent each account as its own resource, which I assume responds correctly otherw…

The action is "close". The status may or may not be "closed", but that's not what he's doing. Read a little farther. In the brief example JSON for the accounts, there is no "status" property. In fact, there are four actions available on the account: {"rel": "deposit", href: "/account/4502278/deposit"}, {"rel": "withdraw", href: "/account/4502278/withdraw"}, {"rel": "transfer", href: "/account/4502278/transfer"}, {"re…

What HTTP methods should be callable on those URL endpoints? Presumably POST should trigger the action it is not idempotent, but what content should we be POSTing?

Re: REST Anti-patterns

#60

Post by goostavos »

fzilla wrote: post #37
strictnein wrote: post #23

Earlier quoted context omitted.

The action is "close". The status may or may not be "closed", but that's not what he's doing. Read a little farther. In the brief example JSON for the accounts, there is no "status" property. In fact, there are four actions available on the account: {"rel": "deposit", href: "/account/4502278/deposit"}, {"rel": "withdraw", href: "/account/4502278/withdraw"}, {"rel": "transfer", href: "/account/4502278/transfer"}, {"re…

Yeah I'm saying this is wrong :\ This isn't how REST is supposed to work

Ah, and therein lies the classic problem. Nobody is doing REST "right," but I'm yet to see anyone point to a de-facto example.

Fielding's dissertation isn't a spec, which pretty much means everyone can come up with their own little slice of how it should be done and then say they're doing it right.

The true rule of REST: whoever is blogging/commenting about it at the time is doing REST right, all others are confused and incorrect.

Post reply on HN