CODEWITHSUNDEEP
jsonresthttp
ahjmorton
ahjmorton

Reputation: 965

REST method for altering state of sub resources

Currently I have a REST API that represents a resource that has two different sub resources : errors with the resource and valid entries. Previously this structure was immutable : if you had an error it would stay an error and if you had valid entries they would stay as valid entries. As an example below is a sample JSON output :

GET /resource/1
{
  "resourceId" : 1,
  "errors" : [ 
    { "id": 1, "errorDetails" : "it isn't right" } 
  ],
  "validData" : [
    { "id": 1, "message" : "it's good!" }
  ]
}

Requirements have arise to allow correction of errors to make them valid. So in essence the result after the operation would be 

GET /resource/1
{
  "resourceId" : 1,
  "errors" : [],
  "validData" : [
    { "id": 1, "message" : "it's good!" },
    { "id": 2, "message" : "Corrected, old data was : it isn't right" }
  ]
}

The correction process would take some extra parameters then either a) create a new error entry as the supplied parameters didn't correct the error or b) create a new valid entry as the error has been corrected.

From a REST perspective what is the best way to represent this? So far I have the following ideas :

  1. Have a PUT / DELETE on the errors i.e. PUT /resource/1/errors/1 with the parameters. This will cause a new sub-resource to be created under /resources/1/errors or /resources/1/validDate
  2. Have a PUT on the root resource i.e. PUT /resource/1 with a reference to the error as you're modifying the resource as a whole by moving from one side to the other

Upvotes: 1

Views: 32

Answers (1)

Robert Bräutigam
Robert Bräutigam

Reputation: 7744

I would go with option 1 and make the errors resources themselves, since they mean something and have some behavior as well (checking whether they can be removed). It should be a POST though, since it is some processing on server side necessary (if I understand that currectly) to determine what actually will be done.

Everything that is somehow "important" should be a resource, so option 2 seems sub-optimal.

Minor note: Everything that already has an id probably should be a resource, that is true for the "data" too. Also, unless there is a really good reason to explicitly leak the Ids of these things, I would rather give back the URIs to these things instead of the Ids.

Upvotes: 1

Related Questions