By Jonathan Komar


2019-09-11 09:13:01 8 Comments

This is a PUT vs PATCH question. The question title in other words: Normally, a URL of an underlying object exists at /object/{id}. Is it still idempotent to add a URL /object/{id}/member and call PUT on that specific member?

Minimal Example

If I have resource called Booking that looks like this

public class Booking {
    private bookingId;
    private name;
}
//accessors ...

I think the PUT and PATCH stuff is clear. My confusion stems from deciding on what idempotency refers to...

  • idempotency of response to a given URL? OPTION 1
  • idempotency of the underlying data objects (Java) as opposed to members? OPTION 2

If the first case is true, then I would expect that it is RESTful to create a specific call to an object member of Booking like this:

PUT /booking/{id}/name GRAY AREA HERE? (NORMALLY A PATCH OP AT booking/{id})

{
   name: "Joe Schmoe" 
}

In this case, the underlying object has been changed, but the resource remains idempotent (GET here would return the same and subsequent PUTs like above would not change anything), because the resource is specific to an object member? Or by altering a member, did I break the idempotency law?

If the second option is true, and URLs should not be made specific to object members, then I would expect to use PATCH on a member at a URL resource that represents the entire object to update specific object members like this:

PATCH /booking/{id}*

{
    name: "Joe Schmoe"
}

I expect that it is NOT RESTful to do the following. It would clearly break idempotency at of the resource URL. Let me know if I am mistaken here.

PUT /booking/{id}

{
   name: "Joe Schmoe"
}

1 comments

@cassiomolin 2019-09-11 09:54:24

First of all, keep in mind that idempotency is a property of HTTP methods (and not a property of the resources). Quoting the RFC 7231, which is the document that currently defines the semantics and content of the HTTP/1.1 protocol:

4.2.2. Idempotent Methods

A request method is considered "idempotent" if the intended effect on the server of multiple identical requests with that method is the same as the effect for a single such request. Of the request methods defined by this specification, PUT, DELETE, and safe request methods are idempotent. [...]

Have a look at my previous answer for further details on what idempotency is.

So a request with an idempotent HTTP method can be performed multiple times and the same effect will be produced in the server. Understand effect as the state of the resource on the server, even if a resource has multiple identifiers.

And bear in mind that status codes are not relevant from the idempotency point of view.

Related Questions

Sponsored Content

34 Answered Questions

[SOLVED] PUT vs. POST in REST

  • 2009-03-10 14:25:20
  • alex
  • 2300486 View
  • 5267 Score
  • 34 Answer
  • Tags:   http rest post put

9 Answered Questions

[SOLVED] REST API - PUT vs PATCH with real life examples

11 Answered Questions

[SOLVED] Should a RESTful 'PUT' operation return something

14 Answered Questions

[SOLVED] Representational state transfer (REST) and Simple Object Access Protocol (SOAP)

  • 2008-10-16 19:24:14
  • Vicky
  • 278157 View
  • 722 Score
  • 14 Answer
  • Tags:   rest soap

12 Answered Questions

[SOLVED] RESTful URL design for search

  • 2008-10-16 04:51:20
  • Parand
  • 186459 View
  • 415 Score
  • 12 Answer
  • Tags:   rest

3 Answered Questions

10 Answered Questions

[SOLVED] Understanding REST: Verbs, error codes, and authentication

  • 2010-01-04 19:55:36
  • Pekka
  • 130900 View
  • 595 Score
  • 10 Answer
  • Tags:   web-services rest

4 Answered Questions

[SOLVED] RESTful resource - accepts a list of objects

  • 2010-07-07 21:47:30
  • Chris Dutrow
  • 13616 View
  • 11 Score
  • 4 Answer
  • Tags:   rest

Sponsored Content