Comment by simonw | Hacker News Reader

Comment by simonw | Hacker News Reader

I agree with some of this - I've never found value in the different PUT/PATCH/etc verbs, and I think the lack of examples of good "pure" REST APIs indicates that pure REST doesn't work easily for most projects.

I do think this throws away some pieces that are really valuable though:

1. URLs for concepts are a good idea

2. Distinguishing between read-only operations (which can be cached) and write operations using GET and POST verbs is useful

Personally I've found myself settling on "REST-ish" JSON APIs:

- Every domain concept has a URL, and a standard consistent JSON representation that's also returned by list endpoints

- GET for read operations, POST for anything that performs a write

- I don't like content negotiation via the Accept header, so instead if I need to support alternative representations I'll do that using file extensions, .json vs .csv for example

Yep, this is pretty much what I've settled on myself.

GET for read, POST for write. And a url made of a slash-terminated "resource" followed by an "action" verb. user 123 + edit = "/user/123/edit" ; user 123 + default(show) = "/user/123/" ; list of users = "/user/list" ; etc.

When applied to web pages, it means you can have <form action="edit"> and the "action" attribute of the form directly matches the "action" of the backend/router/API. I like that, it makes me feel warm and fuzzy. :-)

Content negotiation is it just for taste or do you have some other reasons?

I find one good use case for them when a browser can make good use case with a SSE whilst another client just needs a regular _json_ response

I don't like how undiscoverable it is, and how it blocks browser-based debugging. I'd much rather be able to open an issue with a GET link to a stable representation, where possible.

Cloudflare doesn't support it for caching (more specific Cloudflare doesn't obey the Vary: cache header).

1. URLs doesn’t matter in REST because interactions are hypertext-driven.

2. The method to use is implied by the relationship of a link.

Implicating isn't a great way to document an API. You could easily do something you didn't intend to do, which could be no big deal or extremely costly.

Reply on news.ycombinator.com