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

31–40 of 133 posts

Re: REST Anti-patterns

#31

Post by PaulHoule »

macca321 wrote: post #30
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…

There's nothing to stop someone putting resources on an api which do the one thing a client needs to do. And what you describe nothing to do with REST, it's to do with overly fine-grained API design, without taking your users into account.

I have frequently seen it done in the name of REST, and had people argue that an effective API is an evil RPC.

Re: REST Anti-patterns

#32

Post by jackcosgrove »

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…

This can be resolved somewhat with a SOA or microservices, where one call from a client triggers multiple calls from one service to another. Sure there's overhead (which can be mitigated in a shared data center) but I think this is at least balanced out by modularity.

Re: REST Anti-patterns

#33

Post by caseysoftware »

binarymax wrote: post #21
zeveb wrote: post #17

Earlier quoted context omitted.

Closing it may not delete it, but simply mark it as closed.

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.

Re: REST Anti-patterns

#34

Post by fzilla »

caseysoftware wrote: post #25
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…

This depends on your data model. If "status" is just a property on the accounts resource and doesn't have further meaning, I would tend to agree with you. If "close" is an action or activity that acts upon an accounts resource, then his approach makes sense. Since the context is an account that we "need to close," I would assume the author is talking about something more complex than a database field. It's probably a…

REST is just a representation of the underlying data. What does it matter if "status" is a database field or not?

More specifically, it shouldn't have to matter to consumers. Because of the way REST and HTTP work, clients intuitively understand retrieving and modifying resources (via GET, POST, PUT, PATCH and DELETE). But they don't understand interacting with special-purpose endpoints (POST always implies "make a new thing" so it's weird in this context).

Your consumers should not have to learn weird idiosyncrasies in your API because you let your data model bleed into the interface.

Re: REST Anti-patterns

#35

Post by barrkel »

HATEOAS is much less important for programmatic APIs. You either hard-code knowledge of the URL scheme in the API client, or you hard-code knowledge of the payload schema in the API client. There isn't a huge amount of difference here IMO, especially if you have some kind of versioning mechanism in your URL routing.

Hard-coding URL scheme permits more pipelining and concurrency in the client. Embedding URLs in payloads forces sequencing. This alone can make the templated URL scheme a win for interactivity.

Re: REST Anti-patterns

#37

Post by fzilla »

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…

Yeah I'm saying this is wrong :\

This isn't how REST is supposed to work

Re: REST Anti-patterns

#38

Post by caseysoftware »

fzilla wrote: post #34
caseysoftware wrote: post #25

Earlier quoted context omitted.

This depends on your data model. If "status" is just a property on the accounts resource and doesn't have further meaning, I would tend to agree with you. If "close" is an action or activity that acts upon an accounts resource, then his approach makes sense. Since the context is an account that we "need to close," I would assume the author is talking about something more complex than a database field. It's probably a…

REST is just a representation of the underlying data. What does it matter if "status" is a database field or not? More specifically, it shouldn't have to matter to consumers. Because of the way REST and HTTP work, clients intuitively understand retrieving and modifying resources (via GET, POST, PUT, PATCH and DELETE). But they don't understand interacting with special-purpose endpoints (POST always implies "make a ne…

No, REST and HTTP are implementation details of the technology.

An API is a representation of business workflows and processes. The more accurately you describe or map those to the real world processes, the better your and your consumers' understanding will be.

Re: REST Anti-patterns

#39

Post by recursive »

EugeneOZ wrote: post #5

"Correct POST /accounts/4402278/close" bullshit. POST should not contain all details in URL. POST can have body and each query should not be unique. Stopped reading after that.

URLs should... well... locate a resource. The resource is an account.

Re: REST Anti-patterns

#40

Post by PaulHoule »

jackcosgrove wrote: post #32
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…

This can be resolved somewhat with a SOA or microservices, where one call from a client triggers multiple calls from one service to another. Sure there's overhead (which can be mitigated in a shared data center) but I think this is at least balanced out by modularity.

It's very different "inside the data center" or "inside the cloud" from "services provided to the network edge".

If you want: (i) any chance of all at building a system that works and (ii) happy users, you should codesign the client, protocol and client-facing server if you are providing services to the edge (Web, IoT, etc.)

Inside the data center you can do something else.

The key thing is that REST principles are orthogonal to "a good API", "a successful project", etc.

Post reply on HN