[brosciencecode]

Are you mistaking POST for PATCH? What I've been working with is:

- POST creates

- PUT replaces (i.e. edit, but you need to provide the whole resource)

- PATCH edits (i.e. you can only provide some fields)

APIs rarely implement all these properly in practice but that's my understanding of the theory.

[wak90]

I remember getting an interview question wrong when I said "yeah a get is supposed to just respond with data but you're writing it, you can make it do whatever you want"

[charrondev]

I mean most GET requests have at least one side effect: one or more cache writes.

I’ve also implemented some GET endpoints that are a GET but have a side effect of marking something as read. (Normally as a variant to an existing endpoint for sessioned user).

I would expect at a minimum though if you are doing writes during a GET it should be idempotent.

[kiitos]

Well, caching a response to a GET request is always going to be subject to variables like Etag and other hashes of the request, time limits, etc. which all ensure that responses, even old responses, are never _wrong_, they're at worst _stale_.

That's different, and safer, than something like a "read" bit on an entity, presumably tracked in an application data layer. I don't think you can mark something as "read" in your application from a GET request. Even if your server sees the response to that GET request as successful, it doesn't necessarily mean that the requesting client actually successfully received the response. As one of infinitely many possible counter-examples, consider a middlebox between a client and your server, where one client request to the server may generate N requests from the middlebox to the server.

[charrondev]

While you might technically correct about using a GET to mark a “read” bit as correct on some activity, in reality there’s a trade off to doing it in a PUT.

Let’s say you have some notification resource which is a link redirecting to the thing that triggered the notification. Ideally the notification will automatically be marked read after the user sees the thing they clicked.

My setting the read bit in the GET that makes the redirect you open up. 2 negative possibilities:

- if someone could guess the GUIDs of the notifications they could CSRF a users notifications as marked read. (Unlikely and low impact if it does occur). - Adds the potential that the client may not have loaded page after the redirect and seen the resource.

There is a UX tradeoff now though if we make this a separate PUT after the page loads:

- in a web application context the user will have to either enable JavaScript so the app can automatically mark this as read or have a separate form on every landing page to mark it as read.

Another alternative would be to make this a POST form to view the notification that redirects but you have in effect the same issue of the user maybe not loading the page after the redirect.

At the end of the day for something as minor as a notification being marked read (as a result of a user clicking directly on it), some idempotent modification can work out and be easy to implement.

Now to be clear I am referring to a purpose built endpoint for a web application.

We expose 1000s of truly restful endpoints that are used outside of a web context and something like this doesn’t really make sense for them.

[kiitos]

You probably wouldn't use a PUT for anything like this, true. But if you're going to mark a message as "seen" in a way that would impact a UI widget like an "unread notifications" red dot, then you almost certainly want to make sure that the state-changing request for that message is a POST, not a GET.

There are just so many ways for GET requests to be delivered to a server (or load balancer, or IP, or domain, or...) multiple times for a given client request. That capability is built in to HTTP and exploited in more places than you can ever hope to account for, or even detect.

[eddd-ddde]

During any serious side effects with a GET is a bad idea because of xsrf anyways

[puika]

This is indeed the standard, AFAIK. Not sure what resources mention otherwise but it seems like a lot, judging by the comments around

[cryptonector]

POST is a kitchen sink. It can do anything. If it creates it must return a 201 with the new resource's location, otherwise if it succeeds but does not create a new resource (just modifies one) then it must return 200.

[richardwhiuk]

PUT can create - depending on whether the resource name is client or server determined.