I want a server to be a producer of tasks for the client to process and be sent back. What is the proper HTTP method
in RESTful approach to create and return a new resource?
This seems silly, but the natural way seems to be GET /task/
, or more verbosely GET /new_task/
. A task is being created and returned. But this doesn't seem right. POST
also doesn't seem natural. Client does not want to POST
any data. It rather requests it.
Use Case:
For example. I want to produce some tasks to perform, let's say some exercises. They need to be processed and sent back. My idea is to provide uri with GET
method, to obtain a task. Save on the server that a task was obtained and save the time-out for this. Technically a task can be retrieved many times, and GET
doesn't change it in any way, so it even seems idempotent. If a user POST
s answer to it the server will reply differently based on the saved time-stamp. However, I feels like at the same time I am also creating a new resource, i.e. (user; task; time-stamp)
which semantically is "given-homework". What is the view in such case?
My ideas:
GET /resource/
and create/generate and send it back. Let's say:{ "self": "http://super-service/resource/<new_id>", "data" : "Ipsum Lorem... Your random stuff." }
Is this really idempotent? The "self" isn't really a mirror of GET
this seems counter-intuitive for a GET
request.
- Another way I can imagine is something like to
POST
a request for the resource to be created. E.g:POST /create_task/
which I don't think is a proper solution because it has a verb in URI. But one can workaround it let's say via:POST /task_request/
, so now I am posting a request for a task, but it feels like fiddling with semantics to get it pretty. Still not sure if proper. The data in the response might be completely unrelated to thePOST
. Is that fine? Can the new data be a response (e.g. like from the case 1.)
I'd like to ask for motivation behind the proposed approach. So I can understand and learn the thinking process.