CODEWITHSUNDEEP
rest
Chris Dutrow
Chris Dutrow

Reputation: 50362

REST API - Opinion needed on architecture

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'.

Upvotes: 2

Views: 538

Answers (3)

Tarlog
Tarlog

Reputation: 10154

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.

Upvotes: 2

Maxym
Maxym

Reputation: 11896

As for me it just depends on how additional info is going to be used. For my customers responseTime is not a question (or at least I think so :), they just need that response. For me as developer it can help debugging. So when customer gives me slow request I can test it easy, and that extra information could help. Here I mean that it is possible to create simple url as you specified /data/{table name}/{row key} and send just response according to that request, and you can make one more url /data/{table name}/{row key}/debug or whatever else to get the same data with additional info like "reponseTime". Just an idea ;)

UPDATE: Ah yes, forgot: do not use table-name as part of your url, at least modify its name. I don't like to tell anybody how my tables are called, if somebody is going to hack my DB injecting extra code I would like her to spend more time looking for any information, instead of giving her info on a plate :)

Upvotes: 3

Abdullah Jibaly
Abdullah Jibaly

Reputation: 54780

I don't see anything wrong with this, looks pretty standard to me. I'm not sure what you are planning to pass in queryArguments, is this where you would specify a callback to execute for JSON-P clients? Only thing I'd recommend you keep in mind is that REST deals with resources, and that does not necessarily map 1-to-1 with tables. Instead of using a row key you might want to have some type of GUID or UUID that you can map to that resource.

Upvotes: 2

Related Questions