History   View   Links to this page 2013 January 8 | 10:32 am

Usage Scenario: Partial Update of AMR

A REST client wants to update a small subset of the properties of a potentially large Architecture Management Resource (AMR). The client is not interested in any of the other properties of the resource, and does not want to GET and then return them. Instead the client wants to just update the ones it is interested in (e.g. dcterms:title and dcterms:description).

This scenario is based on the emerging work on the topic by the Core workgroup.

Partial update of existing properties

  1. An authenticated and authorized REST client has the URI of a resource that it wants to update the title and description of. It first gets the latest ETag of the resource via a HEAD request.
  2. The client constructs a resource that includes the updated title and description. The client does not know the current title and description, it just wants to set it to the values it has.
  3. The client uses the PATCH or PUT method to perform the update. If successful the service provider responds with a 200 OK, and an updated ETag for the resource. If not an appropriate response code (e.g. 400 Bad Request) is returned.

Partial update to remove existing property

  1. An authenticated and authorized REST client has the URI of a resource that it wants to remove a property from. It first gets the latest ETag of the resource via a HEAD request.
  2. The client constructs a resource that includes to the service provider that the one property (e.g. dcterms:description) is to be removed (not set to empty string).
  3. The client uses the PATCH/PUT method to update the resource. If successful the service provider responds with a 200 OK, and an updated ETag for the resource. If not an appropriate response code (e.g. 400 Bad Request) is returned.

Partial update to modify a rdf:Seq property

  1. An authenticated and authorized REST client has the URI of a resource that it wants to update the title and description of. It first gets the latest ETag of the resource via a HEAD request.
  2. The client constructs a resource to indicate to the server that a specific element in a sequence (identified by index) is to changed, and that another is to be deleted, and a third is to be inserted.
  3. The client PATCH/PUT the resource to the service provider, and if successful the service provider responds with a 200 OK, and an updated ETag for the resource. If not successful an appropriate response code (e.g. 400 Bad Request) is returned.