views:

36

answers:

2

I'm working in a research group where we intend to publish implementations of some of the algorithms we develop on the web via a RESTful API. Most of these algorithms work on small to medium size datasets, and in many cases, a user of our services might want to run multiple queries (with different parameters) on the same dataset, so for me it seems reasonable to allow users to upload their datasets in advance and refer to them in their queries later. In this sense, a dataset could be a resource in my API, and an algorithm could be another.

My question is: how should I let the users upload their own datasets? I cannot simply let users upload their data to /dataset/dataset_id as letting the users invent their own dataset_ids might result in ID collision and users overwriting each other's datasets by accident. (I believe one of the most frequently used dataset ID would be test). I think an ideal way would be to have a dedicated URL (like /dataset/upload) where users can POST their datasets and the response would contain a unique ID under which the dataset was stored, but I'm not sure that it does not violate the basic principles of REST. What is the preferred way of dealing with such scenarios?

+3  A: 

According to this you should not have dedicated URI, and rather handle POST to /dataset/ as creation.

vartec
Great, thanks - and shame on me, usually it is Wikipedia where I look for things in the first place, but it never occurred to me that it can provide insights into REST API design principles.
Tamás
+1  A: 

Your idea is not violating the principles of REST :)

The preferred way is to use POST and return the path to the newly created resource in the Location header.

In your case. Client POSTs to /dataset. The server generates an identifier and returns a reference to the dataset in the Location-header:

Location: /dataset/1234

The response status should be 201 (created)