Question 40066 in PHP Question posted in
Official manual can be found here.

Should I use PATCH with empty body or HEAD in my REST API? – PHP

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
Tags:

2

Answers


  1. 0

    The standard is :

    • POST Create
    • GET Read
    • PUT Update/Replace
    • PATCH Partial Update/Modify
    • DELETE Delete

    In your case PATCH seems the better choice

    HEAD method is for response retrieval, like a GET without body, not for update

    Login or Signup to reply.
  2. 0

    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.

    It is okay to use POST.

    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.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search