I want to design my rest endpoint with the appropriate method for the following scenario. There's kind of slides that should be displayed on the homepage for a period of time depending on some other logics. That's why I will need to record the last view datetime for the connected user.
So, as soon as the user views these slides, normally, a call to the API is made to record the date of the last view.
A Request Event Listener will listen to my request and then update the connected User::$receptionDate props
Should I use a PATCH method for my end point as :
PATCH with empty body {} : /users/me
OR a HEAD method :
HEAD : /users/me
Should I should a PATCH method for my end point...
Almost certainly not. The currently registered reference for PATCH is RFC 5789:
PATCH, which is used to apply partial modifications to a resource.... The PUT method is already defined to overwrite a resource with a complete new body, and cannot be reused to do partial changes. Otherwise, proxies and caches, and even clients and servers, may get confused as to the result of the operation.
In other words, PATCH is a mechanism that we use to tell a server to modify its (internal) representation of a resource to match our copy -- these are remote authoring semantics.
An empty body on a PATCH message only makes sense if you are using a patch document format where an empty patch document is meaningful.
PATCH could make sense if you were sending to a server a new value for the receptionDate property, and didn't want to PUT the entire representation. For example, you might use an application/json-patch+json document
[
{ "op": "replace", "path": "/receptionDate", "value": "2023-04-10T12:34:56.789" }
]
But if you are intending that the server compute its own value for receptionDate, then PATCH has the wrong semantics.
a HEAD method
Not a good choice: HEAD has semantics described by RFC 9110; general purpose components are allowed to assume that HEAD requests are safe, which is to say free of spooky side effects.
Among other problems that you might run into: HEAD is cacheable by default -- a HEAD request will not necessarily travel all the way to the origin server if a re-usable response is available at some intermediate point.
General rule - if you are intending to send information (explicitly or implicitly) to a server, then you should use POST unless one of the more specific unsafe methods is a better fit.
It may be useful to review Fielding's 2002 remarks on GET
HTTP does not attempt to require the results of a GET to be safe. What it does is require that the semantics of the operation be safe, and therefore it is a fault of the implementation, not the interface or the user of that interface, if anything happens as a result that causes loss of property
This holds generally - each HTTP method has its own semantics; if the server doesn't implement its handlers to respect those semantics, that's fine provided that the server accepts responsibility for any errors that result.
So you can implement GET/HEAD request handlers that do unsafe things, and PATCH handlers that don't mean patch, and so on. The server always has the right to maintain its resources as befits its needs.
But general purpose components are allowed to assume that your server understands messages the same way every other server on the web understands messages (that's part of the uniform interface constraint); any messes that happen because your server instead tries to be a very special snowflake is your own responsibility to clean up.