Hacker News Reader

Comment by EugeneOZ | Hacker News Reader

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

View on HN

I disagree. In the example, account 4402278 is a resource represented at /accounts/4402278; actions on that resource should be performed … on that resource, not on some other resource (e.g. all accounts, at /accounts).

This also gives increased future-proofing, since someday one might have uncloseable accounts; those accounts could still live under /accounts, but would simply have no /close endpoint (as opposed to having /accounts/close, which sometimes works and sometimes doesn't).

"close" is a verb, so it's not a resource, it's a method and 4402278 is just argument of that method.

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

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

In your mind, what does URL stand for? It's an acronym.

Do you really expect to get resource data when you send POST or DELETE request? If yes, then web (and REST) is not as perfect as you expect.

The REST design pattern does require that your URLs are structured in this way, and I don't think that's really open to debate. Whether or not all HTTP APIs need need to be RESTful is a different issue.

Yeah, just

PATCH /accounts/4402278

with parameter ACTIVE: 0

Reply on news.ycombinator.com