restcookbook | Jekyll cms site for restcookbook.com | Plugin library

In REST API if I have a resource which creation could take considerable amount of time I could return a temporary resource with status code 202. Client then could poll this temporary resource until the actual resource is created and get redirected to it when it'd done (with 303 status code). Something like described in http://restcookbook.com/Resources/asynchroneous-operations/.

Is there any standardized way to created such resources in OData?

When you use PUT endpoint to create resource in REST api, what should the endpoint return for subsequent calls after returning 201(created) for the first call? 403(cannot create since the resource already exist)? 200(updated to the same exact object?) if you change the status code after one call(201-> 200 or 403), isn't that a violation of idempotency? I looked everywhere but all I can find is you can use PUT to create but nowhere it said about status code change after resource creation. In short my question is that PUT is an idempotent method, but when it is used in resource creation, can it still change it's return status code from the following calls?

p.s. After first calls, it will be idempotent(constantly 403 or 200). And ideally I want to be able to tell the client that the resource is already created and you shouldn't call this again.(403) I know using POST is an alternative but as ID is already known to client at the point of creation I wanna use PUT method but want to know the proper REST way in terms of idempotency.

=================================================================== References of Using PUT endpoints for creating resources http://restcookbook.com/HTTP%20Methods/put-vs-post/ https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI. The URI in a POST request identifies the resource that will handle the enclosed entity. That resource might be a data-accepting process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request identifies the entity enclosed with the request -- the user agent knows what URI is intended 9.6. PUT If a new resource is created, the origin server MUST inform the user agent via the 201 (Created) response. If an existing resource is modified, either the 200 (OK) or 204 (No Content) response codes SHOULD be sent to indicate successful completion of the request.

http://zalando.github.io/restful-api-guidelines/http/Http.html

PUT requests are usually robust against non-existence of resources by implicitly creating before updating

successful PUT requests will usually generate 200 or 204 (if the resource was updated - with or without actual content returned), and 201 (if the resource was created)