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

61–70 of 133 posts

Re: REST Anti-patterns

#61

Post by qyv »

blowski wrote: post #43
fzilla wrote: post #37

Earlier quoted context omitted.

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

Can you give an example here of how you think it should work, please. This is one area of REST with which I have a lot of trouble.

For the deposit/withdrawal/transfer set, depending on the specifics of how they are actually moving the amounts around, would likely be best served as their own resource. Since a deposit/withdrawal is just a transfer anyways, just having "/transfer" would be likely be good. The connotation here is that the client is creating a transfer on the server. The body for this request could take the relevant account numbers (you need two accounts), and the sign on the amount would denote if the amount is being deposited or withdrawn.

Re: REST Anti-patterns

#62

Post by pc86 »

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.

DELETE simply means subsequent calls to GET should not return that object.

So you can call DELETE on an account then your next GET returns a 404 because you deleted it from the database, or you can call DELETE and your next GET returns a 405 because the account has been closed and you're not allowed to call GET on a closed account. Both are totally within the spirit of what DELETE is supposed to accomplish, and I'm sure there are a half dozen other ways to architect it completely within the spirit of DELETE and REST as well.

Re: REST Anti-patterns

#63

Post by PaulHoule »

drj077 wrote: post #51
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 iss…

This type of approach can be great. It is parallel to the idea to the "business is an exchange of documents", and the documents represent "transactions" in the sense of "an invoice", "a packing slip", "a deposit slip", "an order", etc.

Re: REST Anti-patterns

#64

Post by barrkel »

macca321 wrote: post #46
barrkel wrote: post #35

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 payloa…

The dream is that your client can dynamically update itself or seek out ways to process new, incomprehensible things* that it encounters while traversing a rest request (see "Code-on-demand in REST literature). If you think this is possible in the wild or not is another matter. *each nugget of data can be versioned and meaninged independently

That, and the semantic web, and pluggable components from different vendors using standardized interfaces, and other architecture astronaut ideas of software composition. Any day now.

Re: REST Anti-patterns

#65

Post by blowski »

qyv wrote: post #61
blowski wrote: post #43

Earlier quoted context omitted.

Can you give an example here of how you think it should work, please. This is one area of REST with which I have a lot of trouble.

For the deposit/withdrawal/transfer set, depending on the specifics of how they are actually moving the amounts around, would likely be best served as their own resource. Since a deposit/withdrawal is just a transfer anyways, just having "/transfer" would be likely be good. The connotation here is that the client is creating a transfer on the server. The body for this request could take the relevant account numbers (…

So I would make a request like:

    POST /transfer

    from_account_id=12345&to_account_id=67890&amount=10
Perhaps I've misunderstood your comment, as I don't really understand why this is better than the original:

    POST /accounts/12345/transfer

    to_account_id=67890&amount=10
or even:

    POST /accounts/12345/withdraw

    amount=10

Re: REST Anti-patterns

#66

Post by robzhu »

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…

You might want to check out GraphQL: http://graphql.org/. One of its killer features is the ability for clients to specify exactly the data it needs and obtain it in a single request/response.

Re: REST Anti-patterns

#67

Post by seagreen »

PaulHoule wrote: post #63
drj077 wrote: post #51

Earlier quoted context omitted.

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 iss…

This type of approach can be great. It is parallel to the idea to the "business is an exchange of documents", and the documents represent "transactions" in the sense of "an invoice", "a packing slip", "a deposit slip", "an order", etc.

> "business is an exchange of documents"

Did you just make up this phrase? It's really good!

Re: REST Anti-patterns

#68

Post by 33degrees »

blowski wrote: post #43
fzilla wrote: post #37

Earlier quoted context omitted.

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

Can you give an example here of how you think it should work, please. This is one area of REST with which I have a lot of trouble.

One way to approach it would be to have consider deposits, withdrawals, and transfers as subresources of a specific account. So you could POST to "/account/4502278/deposits" to create a new deposit, which would then live at a URL such as "/account/4502278/deposits/87162". And instead of separate subresources for all of these different transaction, it could just be one "transaction" subresource.

In the case of closing an account, it depends on what actually happens when you do so, but I would normally have a "status" attribute and use PATCH to update that.

Re: REST Anti-patterns

#69

Post by SEJeff »

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 was a surprisingly good talk on just that: https://vimeo.com/20781119

Where the server goes from requiring multiple requests to a single request without changing the clients whatsoever. So, I feel you're comment is on the right path (less http requests are better for the client and server), but might not realize that things can be optimized further.

Re: REST Anti-patterns

#70

Post by sidlls »

macca321 wrote: post #46
barrkel wrote: post #35

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 payloa…

The dream is that your client can dynamically update itself or seek out ways to process new, incomprehensible things* that it encounters while traversing a rest request (see "Code-on-demand in REST literature). If you think this is possible in the wild or not is another matter. *each nugget of data can be versioned and meaninged independently

Sounds a bit like UML+Rational, visual programming, and every other one size fits all panacea, to be honest.

The whole notion of HTTP as an application data transport is terrible. We've hacked at it to create a great number of wonderful web based apps, but I can't help thinking there's a better way.

Post reply on HN