Actions against CRUD in REST

Is it appropriate to perform actions with REST, except for simple creation (POST), reading (GET), updating (PUT) and deleting (DELETE)? I am new to all RESTful theology, so bear with me, but how should I do the following:

  • I have a web service that needs to talk to another web service. Web Service A must “reserve” an object on Web Service B. This object has a timeout, but can be deleted immediately if necessary. This is essentially an illustrious permission system that requires web services to reserve a place in web service B before taking any action.

My initial thought was to 1. enable some kind of authentication, 2. reserve a place in the server’s response to the GET call and return the result, and 3. ensure the object immediately stops by calling DELETE, is it still RESTful?

+8
rest restful-architecture
source share
3 answers

Yes, it’s normal to take rest activities. The important thing is that these actions should be guided by the representations you presented.

If you think about how a website works (through a browser), you do this all the time: you get an HTML form that allows you to select a series of actions that you can perform. Then you submit the form (usually through POST ) and the action is executed.

It’s good to be able to use DELETE through the software client (something that non-AJAX related requests in browsers are not supported), but the general RESTful approach should be very similar to what you find for websites (i.e. focus should be on submissions: the equivalent of web pages on your system).

GET should not have any side effects, so do not use GET to make the reservation itself, use something like POST instead.

+3
source share

No - unlikely to be calm

From your description ...

2. in the serveride response to the GET call, reserve a space and return the result

GETs should be idempotent. For this reason, your service is unlikely to be calm, because the state of the system after the first GET is different.

You really need to consider that Reservation is a resource , and you should create it using POST in the reservation container, which will return the URI of the new resource in the Location header of the HTTP response. This UrI can be used by Get to return a resource and update using PUT.

The message should be used to extend an existing resource and Put to replace the state of the resource. In your case, think that Post will update the reservation list and return the URI of the new resource (not just me). Put can be used to change the state associated with a resource identified by UR

+2
source share

You are on the right track, but your object reservation must be with PUT; you are making an object reservation, i.e. change the base object.

PUT is the correct verb here, since you know which resource you are changing, and it should be idempotent for multiple requests.

+1
source share

All Articles