When implementing soft row deletion by setting its status to deleted which method is appropriate?
Should it be DELETE for we are not passing that row to GET anymore or should it be PUT for we are updating the row's status to deleted?
If from the perspective of the user, the resource is not accessible after 'soft deleting' it, (e.g.: you would return a 404), use DELETE. If you can still GET the object after, I don't think I would use DELETE, but PUT may be more appropriate.
Marking for deletion should be on the client side, only POST to the server when you do a proper delete.
If you want to contact the server and do another GET in the meantime - you should do the delete at that point. i.e. your GET should get the latest data, meaning the delete should be done before the GET.
Related
I am not that new to web service but I am not able to understand use of http methods type in restful web service.
I was referring to vogella tutorial here
http://www.vogella.com/tutorials/REST/article.html#rest_httpmethods
They have following description that I am not able to understand somewhat
GET defines a reading access of the resource without side-effects. The resource is never changed via a GET request, e.g., the request has no side effects (idempotent).
(This is fine. No query here)
PUT creates a new resource. It must also be idempotent.
(Ok seems logical, but it must be idempotent why should I care about it? I am not going to call again this service with same data.)
DELETE removes the resources. The operations are idempotent. They can get repeated without leading to different results.
(Ok same question again why do I want to repeat delete query once it is already deleted?)
POST updates an existing resource or creates a new resource.
(This is fine)
I can do delete and putting data with get and post method also, I know I am not able to understand, but why should I use extra method type delete and put, that are provided in web services and what is exactly use for that ?
The most widely used and "known" HTTP methods are GET and POST. But there are other methods, each of which have different semantics. We need to choose the method which has te most proper meaning to the operation the request is meant to perform, and should not "dumb down" the semantics for those only familiar with GET and POST.
DELETE. The semantics are as follows. Once a DELETE request has been processed for a given resource, that resource can no longer be accessed be clients, no ifs, ands, or buts. Any future request to try and retrieve this resource state's representation with GET or HEAD should result in a 404.
That being said, if the semantics of the operation fit the above description, we must use DELETE. Anything less, such as a "soft" delete or some other state-changing interaction, should not be done with a DELETE, better with POST. So it comes down to the semantics, why to use DELETE.
As far as the question "why do I want to repeat delete query once it is already deleted?", well we don't, but if we were to try to use the exact same DELETE request again, it would have the same effect. That is the meaning of idempotency. It really has no bearing on the why. It is just guaranteed protocol semantics
PUT. It's basically used to update a server resource, or create a user resource. In both cases, the URI is known by the user and is the requested URI. For example
PUT /customers/1234
// some body with name to change
The resource URI is known and the client post a message with a representation to update the resource. If the requested operation meats these requirements, then PUT should be used. In contrast if we are creating a new server resource (customer), then we would use POST
POST /customer
// customer representation
Notice the URI of the new customer is not known, because it has not been created. If the POST id successful, we should be back a Location header with the new URI
HTTP/1.1 201
Location: /customers/12345
That was going a little off on a tangent, but getting back to PUT. PUT is idempotent, because no matter how many times we make the exact above PUT request, the result will be the same. No server state will be affected. On the other hand, if we repeated make the same POST request, more new customer may be created
All that being said, we should do out best to follow the protocol semantics. POST is like a wild card for operations that can't be applied to any other method semantics.
And to answer your repeated question, "why should i care?", as noted about DELETE, idempotency is just a matter of guaranteed protocol semantics, it is not a matter of "but i never plan to do this opertion again", it's a matter of "if someone does perform this exact operation again, there is no effect"
There are mainly four methods are used in restful api.they are:
GET-Used to get some resources
POST-Used to create resource
DELETE-Used to remove resource
PUT-Used to update resource.
As you mentioned above we can use post or get for the purpose of put and delete functions.But in programming we can use this method in place where it indicate its purpose so that others will get an idea of what the code is doing
I'm curious to learn more about RESTful design patterns around the PUT call. Specifically, am I violating norms by changing the resource ID as part of a PUT call?
Consider the following...
POST /api/event/ { ... } - returns the resource ID (eventid) of the new event in the body
GET /api/event/eventid
PUT /api/event/eventid - returns the (possibly new) resource ID depending on request body
GET /api/event/eventid - fails if the original eventid was used in the URI
The endpoints for GET and PUT can quickly access the resource if the eventid represents internal resources (like a database record). If the PUT results in the server moving the underlying resource, the ID can change.
Am I violating norms when I do this?
REST is not a strict specification, but more a set of guidelines and best practices that can be followed to build web-services that are easy to understand and work with. So there's nothing that prevents you from changing a resource IDs during a PUT.
That being said, doing so is IMO a bad practice. One of the ideas behind REST is that each resource can be referenced using a URI. In your case this URI is the concatenation of the path and (I assume) an internal ID. This URI could be used by other "systems" and stored as references. If you change the ID of a resource on a PUT, you change the URI and all references to that resource will be broken (404).
If you feel the need to change the ID that is part of the URI, you may not have picked the right property for it. Consider something else that would be immutable (e.g.: tag your resource with a UUID and use it rather than an internal DB ID).
Not addressing your question full on, but this makes me worry:
returns the resource ID (eventid) of the new event in the body
You aren't returning an integer id, and then letting the client construct urls from this, are you? A proper REST application should give url's to resources, not ids.
As for your question - PUT means something like "Create a new resource at this location". You could conceivably reply with a redirect and a Location header, but it's a bit of a strange thing to do. Besides, the semantics of PUT dictates that you send the entire entity with the request, which is probably not what you want in this scenario. Maybe it would be more fitting to use POST in this situation? (E.g. POST on /api/event/1234
I think it's ok; PUT is still idempotent (repeated calls will not lead to other modifications).
Just: I would ensure that the old ID is not reused, and have the api return 301 codes for calls to old ID (in case other clients had links to the resource).
Maybe the initial PUT that modifies the ID should return a 303 code that point to the new resource location, I'm not sure here.
I'm new to symfony2 and doctrine.
here is the problem as I see it.
i cannot use :
$repository = $this->getDoctrine()->getRepository('entity');
$my_object = $repository->findOneBy($index);
on an object that is persisted, BUT NOT FLUSHED YET !!
i think getRepository read from DB, so it will not find a not-flushed object.
my question: how to read those objects that are persisted (i think they are somewhere in a "doctrine session") to re-use them before i do flush my entire batch ?
every profile has 256 physical plumes.
every profile has 1 plumeOptions record assigned to it.
In plumeOptions, I have a cartridgeplume which is a FK for PhysicalPlume.
every plume is identified by ID (auto-generated) and an INDEX (user-generated).
rule: I say profile 1 has physical_plume_index number 3 (=index) connected to it.
now, I want to copy a profile with all its related data to another profile.
new profile is created. New 256 plumes are created and copied from older profile.
i want to link the new profile to the new plume index 3.
check here: http://pastebin.com/WFa8vkt1
I think you might want to have a look at this function:
$entityManager->getUnitOfWork()->getScheduledEntityInsertions()
Gives you back a list of entity objects which are persisting yet.
Hmm, I didn't really read your question well, with the above you will retrieve a full list (as an array) but you cannot query it like with getRepository. I will try found something for u..
I think you might look at the problem from the wrong angle. Doctrine is your persistance layer and database access layer. It is the responsibility of your domain model to provide access to objects once they are in memory. So the problem boils down to how do you get a reference to an object without the persistance layer?
Where do you create the object you need to get hold of later? Can the method/service that create the object return a reference to the controller so it can propagate it to the other place you need it? Can you dispatch an event that you listen to elsewhere in your application to get hold of the object?
In my opinion, Doctrine should be used at the startup of the application (as early as possible), to initialize the domain model, and at the shutdown of the application, to persist any changes to the domain model during the request. To use a repository to get hold of objects in the middle of a request is, in my opinion, probably a code smell and you should look at how the application flow can be refactored to remove that need.
Your is a business logic problem effectively.
Querying down the Database a findby Query on Object that are not flushed yet, means heaving much more the DB layer querying object that you have already in your function scope.
Also Keep in mind a findOneBy will retrieve also other object previously saved with same features.
If you need to find only among those new created objects, you should make f.e. them in a Session Array Variable, and iterate them with the foreach.
If you need a mix of already saved items + some new items, you should threate the 2 parts separately, one with a foreach , other one with the repository query!
I've got a quick question regarding the use of repositories. But the best way to ask is to show a bit of pseudocode and you guys tell me what the result should be
Get a record from the repository with ID of 1 (assume it exists)
Edit a couple of properties
Query the repository again for an item with ID of 1
Result = ??
Should I get the object with updated values or the object without (original state), bearing in mind that since updating the values of properties (step 2) I have not told the repository to update this record.
I think I should get a copy of the original item and not a reference to the edited version.
Please tell me what is correct.
Cheers
The repository pattern is suppose to act like a collection of your objects, so ideally I think it should return the same object instance which would have the updates in it.
Generally there is an identity map somewhere so your repositories can keep track of what has already been loaded. With an identity map, when you fetch an object with the same Id you should always get the already loaded object back regardless of how many times. This is how all more sophisticated ORMs work and is generally a good practice. An identity map helps keep things in sync while you are in the same transaction and saves you some data access.
NHibernate's session has an identity map it keeps track of so you don't have to worry about trying to implement your own in your repositories. Also I believe you can use NHibernate's stateless session if you want to load another instance without change tracking, but I'm not positive on that.
Judging from your past questions I'm assuming you are using LINQ/C#?
If you are using a DataContext and you haven't called SubmitChanges() then you should get back the original unchanged object.
Just tested it. I was wrong, you get back the changed object.
If you set ObjectTrackingEnabled = false on the DataContext you will get the unchanged object.
Has anyone tried out working with the Delete and update command of SPDataSource used in conjunction with SPGridView? If yes, can you share a working example?
There is no way to do this without code. It specifies the query used to first retrieve the item(s) to be deleted, you in turn should add a handler for deleting the items the DeleteCommand retrieves in code.... I know, not very clean, but the SPDataSource is basically only useable for selecting items... CAML is a retrieval only language, it itself does not have any Command either (i.e. SELECT is implicit, DELETE, INSERT UPDATE do not exist in CAML)