Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
can anybody explain what is Idempotent in RestFul WebApi and when use it?
The GET, PUT, and DELETE methods are said to be idempotent; that is, calling them over and over will produce the same result without any additional side effects. For example, the caller should be able to call the DELETE action
on a specific resource without receiving any errors and without harming the system. If the resource has already been deleted, the caller should not receive an error. The same applies to the PUT action. For a given unique resource
(identified by an element URI), submitting a PUT request should update the resource if it already exists. Or, if it doesn’t exist, the system should create the resource as submitted. In other words, calling PUT over and over produces
the same result without any additional side effects (i.e., the new task will exist in the system per the representation provided by the caller, whether the system had to create a new one or update an existing one).
The GET action is also said to be safe. Safe means that nothing in the system is changed at all, which is appropriate for HTTP calls that are meant to query the system for either a collection of resources or for a specific resource. It is important that the idempotency of the service’s GET, PUT, and DELETE operations remain consistent with the HTTP protocol standards. Thus, every effort should be made to ensure those three actions can be called over and
over without error.
Unlike the other three actions, POST is not considered to be idempotent. This is because POST is used to create a new instance of the identified resource type for every invocation of the method. Where calling PUT over and over will never result in more than one resource being created or updated, calling POST will result in new resource instances—one for each call. This is appropriate for cases where the system must generate the new resource’s identifier and return it in the response.
Source: ASP.NET Web API 2: Building a REST Service from Start to Finish
Related
My Grails 4.0.10 app needs to call an external service. The call may take up to 3 minutes, so it has to be async'ed. After reading the doco I wrote a non-blocking service method to perform the call using a Promise without too much trouble.
The documentation describes how async outcome can be displayed.
In my case the outcome affects the database. I must create new domain objects, modify existing domain objects and persist the result in the onComplete closure. The doco is rather quiet on how to do this.
These are my assumptions about the onComplete closure. My question is: Are the assumptions valid? Is this the proper way to do it?
No injected stuff is available, neither services nor (for example) log -- things you normally expect in a service
Database logic must be enclosed first within Tenants.withId if multitenancy is used, and then within withTransaction
withTransaction is prefixed with a domain name. However, other domains may freely be manipulated and persisted in the same closure
Domain instances picked up before the async call may be attached to the current session like this instance.attach() and then modified and saved
If logging is needed, create a new log instance
I want to invoke a (Java) program that e.g. executes a batch file. That execute command should be invoked through a REST API. Do I just use POST to transmit a json string with e.g. {"command": "do"}? What HTTP method should I use or what is the best solution to do this?
The simple answer: it is okay to use POST.
Advanced answer: how would you do it with a website? You'd probably have an HTML page with a form in it, where the form would allow you to collect whatever information you happen to need from the operator. When the operator hit the submit button, all that information would be converted into an application/x-www-form-urlencoded byte sequence, and sent off to the server in the HTTP request.
The HTTP method used by the request would be the one specified by the method attribute of the form.
In the HTML world, that means that we're looking at GET or POST.
GET suggests (but does not promise) that the result of running the program on some collection of form data produces a representation that can be cached and re-used the next time that same form data is used.
If that doesn't make sense, if you prefer to run the program again rather than re-using a previous result, if you want the side effects of running the program each time, then you probably want POST.
The fact that your server happens to respond to this request by running a java program (or any kind of program) is an accident of your implementation. HTTP methods are about the semantics of the request - what each request means.
The technical details of how you implement your handler for a particular request are deliberately hidden behind the facade that is the uniform interface.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I don't know what is the best way to define Rest API convention, what I am doing so far is that
For CRUD operations I will let HttpVerb do the work such as
GET /projects
POST /projects/{projectId}
PUT /projects/{projectId}
DELETE /projects/{projectId}
For operations other than CRUD
POST /projects/{projectId}/changeStatus
And for relation entities
GET /projects/{projectId}/workItems/
And in your case what would you do?
I think you are doing good so far. It will be a lot easier when you can determine a resource. You need to ask yourself what a resource is.
In your case resources are projects, that's why operations need to be bound to the resources (as you can see that projectId frequently appears in uri).
Here are some example is worth looking at
1. document
A document resource is a singular concept that is akin to an object instance or database record. In REST, you can view it as a single resource inside resource collection. A document’s state representation typically includes both fields with values and links to other related resources.
Use “singular” name to denote document resource archetype.
http://api.example.com/device-management/managed-devices/{device-id}
http://api.example.com/user-management/users/{id}
http://api.example.com/user-management/users/admin
2. collection
A collection resource is a server-managed directory of resources. Clients may propose new resources to be added to a collection. However, it is up to the collection to choose to create a new resource, or not. A collection resource chooses what it wants to contain and also decides the URIs of each contained resource.
Use “plural” name to denote collection resource archetype.
http://api.example.com/device-management/managed-devices
http://api.example.com/user-management/users
http://api.example.com/user-management/users/{id}/accounts
store
A store is a client-managed resource repository. A store resource lets an API client put resources in, get them back out, and decide when to delete them. A store never generates new URIs. Instead, each stored resource has a URI that was chosen by a client when it was initially put into the store.
Use “plural” name to denote store resource archetype.
http://api.example.com/cart-management/users/{id}/carts
http://api.example.com/song-management/users/{id}/playlists
3. controller
A controller resource models a procedural concept. Controller resources are like executable functions, with parameters and return values; inputs and outputs.
Use “verb” to denote controller archetype.
http://api.example.com/cart-management/users/{id}/cart/checkout
http://api.example.com/song-management/users/{id}/playlist/play
My understanding of Asp.net restful web service is that for each resource , there are corresponding get,post,delete,put verbs.
But what if I have to submit a request to server that needs to operate on more than one resource?
e.g., for a submit form, I have to ask the server to create an order and in the same request a new order history.
For me , I define an order and an order history as two different resources.
And if we follow the ASP.NET MVC Web api restful web service, we will create two controllers, one named OrderController, and the other one OrderHistoryController.
And each controller has the “get,post,delete,put” verbs.
The question is how can we make sure that the creation of an order and the creation of an order history are in one transaction ?
How and when to call the OrderHistoryController’s post method to create an OrderHistory after the Order’s creation ?
I currently am not sure how to achieve this with OrderHistory being a resource.
Thanks for answering.
For starters, you probably won't want PUT and DELETE operations in OrderHistories. Being able to change/delete history generally isn't a good idea. (You probably don't even want a POST operation on that resource. The server-side logic should create its own OrderHistory objects any time an Order is created/modified/deleted.)
Aside from that...
You don't maintain a transaction (or, more generally, a unit of work) across multiple HTTP requests. Each request would be an isolated and otherwise atomic unit of work in and of itself.
So essentially what you're looking to do here is issue a POST to the Orders resource to create an Order object. The server-side logic in this operation would, within that same unit of work, also create any necessary corresponding records in OrderHistories.
Depending on how you select from these resources, you'd return information from that POST operation needed to query them. For example, it's unlikely that you'd ever want to query an OrderHistory by its own identifier right away, you'd probably query by the Order ID. So when creating an Order object, the returned server-generated ID for that object could be used by the client to query the OrderHistories if they want.
Ultimately, it sounds like the confusion here is from the mistaken notion that a RESTful service is basically a pass-through set of operations to database tables. It isn't. The consuming client shouldn't be responsible for maintaining transactional integrity or relational integrity. The server-side operations maintain that.
Consider I want to develop a RESTfull WebApi for a Book Store. I'll have an Api to get a book info like: books/1.
I want to create a log whenever someone gets a book info. So, later I can produce a report of which book is seen more through the Api.
As in this scenario I'm getting some information it seems more appropriate to use GET. But as it changes some data, it could be a SET request.
Question: Does some changes like Logging effect on idempotent behavior of an action?
The general pattern is that a GET of a resource should not modify the resource in such a way that a subsequent GET of the same resource gets a different result.
Side-effects such as logging are not part of the data model, so are not generally considered to be related to whether the action is idempotent or not.