Question

When designing a RESTful API, providing a spec for updating an entity will force the designer to make some decisions on how the update will behave (an update mode or type). Here are some of the modes I can think of:

  1. If the update body contains null values, ignore them and only update the values with non-null values. (This is the most common behavior, and I think this is called a Delta.)
  2. If the update body contains null values, replace existing values with these null values. (Less common in my experience; I think at one place I worked they called this an Overlay... is that typical?)
  3. Update only values that are currently null, and non-null in the update body. (I'm not sure I've ever seen this form, but theoretically there might be a use for it.)

Basically, my question is, Is there generally excepted terminology used in REST (or even software design in general) for these concepts?

What are different behaviors of updating typically called? (Type, Mode, something else?)

Do these different types/modes have names typically used?

Are there types/modes that I didn't list?

Was it helpful?

Solution

Is there generally excepted terminology used in REST (or even software design in general) for these concepts?

When It comes to REST, I would dare to say no, there's not such terminology.

As Guillaume31 comments, technical details makes sense when we speak about implementation details (how to do) and looking at the question this last seems more appropiated. 1

In any case, REST is agnostic tho this sort of details.

Looking at the Wikipedia description of REST we find nothing about implementations or expected behaviors, but those inerent to the architectural properties and constraints.

We would have to research in the HTTP RFC in order to find something closer to these behaviors, but we would just find the concept idempotency. Which I think, it doesn't answer the question either.

Finally, we would find that in order to describe #2, we could say PUT and #1,3 we could say PATCH. But still not a terminology in the sense you are looking for.


1: In the original answer I did say business rules since I think that the strategy for updates are conditioned by requirements of the business. However, it's missleading. So I had to agreed with guillaume31

OTHER TIPS

I recommend to get familiar with JSON Patch Standard. I use it by myself a lot in my softwares and it makes very easy to handle the updates of the entities in a controlled way. The main idea is to describe every change as operation and send them within a JSON array to server in a single request.

PUT is a no-brainer : the enclosed entity is considered to be a modified version of the resource stored on the origin server, and the client is requesting that the stored version be replaced. (i.e. entirely)

For PATCH:

IMO you won't find anything about that in REST literature let alone HTTP RFCs. It's much too specific. Every server is basically free to implement PATCH as it sees fit along the lines of: The PATCH method requests that a set of changes described in the request entity be applied to the resource identified by the Request-URI. The set of changes is represented in a format called a "patch document" identified by a media type.

Licensed under: CC-BY-SA with attribution
scroll top