Question

I’m designing a REST API. The part I’m working on now involves simply reading objects in the form of JSON data off of the server and modifying them.

The resource that I am thinking of using for this looks like:
/data/{table name}/{row key}

I would like to allow GET and PUT operations on this resource.

The question that I am wrestling with is that I would like to return other data along with the JSON object such as customer messages, the amount of time it took for the round trip to the data base, etc… I would also like to allow for sending query arguments with the payload in cases where the URL would be too long if they were included there.

---

So the resources would work like this:

GET

GET /data/{table name}/{row key}

Server returns:

{
   data:{...JSON OBJECT GOES HERE ....},
   message:"customer messages go here",
   responseTime:'123ms',
   otherInfo:"Yada yada yada;
}

PUT

PUT GET /data/{table name}/{row key}

Client sends as payload:

{
   data:{...JSON object goes here...},
   queryArguments:{...extra long query arguments go here...}
}

I’m afraid this might violate the rules for proper RESTful GET and PUT resources because what you are sending to the server is not exactly what you are getting back out since other information is being included in the payloads. I’d rather not have every operation be a POST as a remedy.

Am I being too much of a stickler with this? Is there some other way I should be structuring this?

Thanks!

Edit::::

I should note that in the resource: /data/{table name}/{row key}, I used ‘table name’ and ‘row key’ for simplicity. This is for use with a noSQL database. This resource is intended to work similar to Amazon S3. “uuid” would actually be a better description than ‘row key’.

Answer 1

I see nothing wrong with your approach.
But if I was implementing this scenario, I would have asked myself the following questions:

1. Who is my resource?
2. Is customer message part of the resource?
3. Is “response time” is part of the resource?

Let’s take as an example “response time”. If it’s part of your resource, your approach is perfect and nothing else should be done.
However, if it’s not part of the resource, return it as a HTTP header. Fair enough.