Should the PATCH method return all fields of the resource in the response body?

26,294

Solution 1

Normally this should be handled through content negotiation. In other words, the client asks for a specific representation if it needs one. The request would look like this:

PATCH /user/123
Content-Type: application/merge-patch+json
Accept: application/vnd.company.user+json
...

In this case, the client expresses that it wants a full user representation as answer. Or it could do:

PATCH /user/123
Content-Type: application/merge-patch+json
Accept: application/vnd.company.object-fragment+json
...

to ask for a generic fragment representation of some object.

You don't have to implement both if you don't want to, in which case you just do your use-case and respond with 406 Not Acceptable to media-types you do not support for the moment.

Solution 2

The specification of PATCH doesn't mandate this.

If you want to control it you may want to look at https://greenbytes.de/tech/webdav/rfc7240.html#return for inspiration.

Solution 3

I don't think the REST specification (btw I think you need to be looking at RFC 6902 for this) enforces any strong rules around this (what you should be returning). I'd rather return the whole resource so that the client can use it any way it needs. Theoretically, the client itself knows what what's been patched (at least what the request was). Getting confirmation from the server might not be trivial (especially given that PATCH is mostly used for collections), or at least not worthwhile.

Share:
26,294
Nigiri
Author by

Nigiri

Updated on June 09, 2020

Comments

  • Nigiri
    Nigiri almost 4 years

    Should the PATCH method return all fields of the resource in the response body?
    Or should it return only updated fields?

    I'm reading this

    For example, if it returns only updated fields, the user could know which fields were updated in the server, while the user updated some fields.

    **Users resource representations**
    name: string
    age: number
    createdon: date
    modifiedon: date
    

    PATCH /users/{userId}
    Request body
    {
      name: 'changedname',
    }
    

    Response body Case1
    {
      name: 'changedname',
      age: 20,
      createdon: 2016-01-01,
      modifiedon: 2016-06-09
    }
    

    Response body Case2
    {
      name: 'changedname',
      modifiedon: 2016-06-09
    }