I must fulfill a web service with PUT as method to send changes. This service is used to change configurations. So, for example, if I send {"varA":true} to url/configurationchageit sets the corresponding variable, and if I send {"varB":true} it changes varB without affecting varA.
I always though that PUT (and searching google it seems as if I am right) just overwrites the resource (or creates it if not existing). Which I think would mean that I always have to send all variables, or the ones that are not sent will be deleted. So, is the behavior of this web service correct??
WITH EXAMPLES
PUT {"varA":true}
Resource content: {"varA": true}
PUT {varB:true}
happening: Resource content: {"varA": true, "varB":true}
what I think should happen: Resource content: {"varB":true}
No, it's not. You probably want to look at the PATCH method instead (see http://greenbytes.de/tech/webdav/rfc5789.html)
Related
I'm making a website right now and need to use django-tracking2 for analytics. Everything works but I would like to allow users to opt out and I haven't seen any options for that. I was thinking modifying the middleware portion may work but honestly, I don't know how to go about that yet since I haven't written middleware before.
I tried writing a script to check a cookie called no_track and if it wasn't set, I would set it to false for default tracking and if they reject, it sets no_track to True but I had no idea where to implement it (other than the middle ware, when I tried that the server told me to contact the administrator). I was thinking maybe I could use signals to prevent the user being tracked but then that would slow down the webpage since it would have to deal with preventing a new Visitor instance on each page (because it would likely keep making new instances since it would seem like a new user). Could I subclass the Visitor class and modify __init__ to do a check for the cookie and either let it save or don't.
Thanks for any answers, if I find a solution I'll edit the post or post and accept the answer just in case someone else needs this.
I made a function in my tools file (holds all functions used throughout the project to make my life easier) to get and set a session key. Inside the VisitorTrackingMiddleware I used the function _should_track() and placed a check that looks for the session key (after _should_track() checks that sessions is installed and before all other checks), with the check_session() function in my tools file, if it doesn't exist, the function creates it with the default of True (Track the user until they accept or reject) and returns an HttpResponse (left over from trying the cookie method).
When I used the cookie method, the firefox console said the cookie will expire so I just switched to sessions another reason is that django-tracking2 runs on it.
It seems to work very well and it didn't have a very large impact on load times, every time a request is made, that function runs and my debug tells me if it's tracking me or not and all the buttons work through AJAX. I want to run some tests to see if this does indeed work and if so, maybe I'll submit a pull request to django-tracking2 just in case someone else wants to use it.
A Big advantage to this is that you can allow users to change their minds if they want or you can reprompt at user sign up depending on if they accepted or not. with the way check_session() is set up, I can use it in template tags and class methods as well.
I'm looking for a way how to deal with a following problem:
Imagine you modify a resource and that subsequently causes update of other resources.
E.g. you issue a PUT to, say /api/orders/1234, which by definition changes state of all other Orders of given user. There may be UI clients that display the table of Orders and they should know that not only single item in the table was updated, but eventually other as well.
Now, is there any standard way how inform a clients about such a situation?
So far I can only think of sending back the 205 Reset Content HTTP status code to inform the client that he should refresh the state, as not just a single thing was changed.
There are multiple solutions.
You can define specific resources as non-cacheable, so the client does not cache them at all. (no-store)
You can try giving a max-age of 0, so the client will have to re-validate those resources always. In this case you might have to implement ETags and conditional GETs, but it will be easier on the server than option 1.
Some push method like WebSockets.
If you really want to "notify" potentially multiple clients of a change, then it sounds like you would need option 3.
However, correctly configured caching is normally good enough. For example you could mark not-yet-executed orders as not cached (max-age=0), but as soon as it is executed, you might mark it to be cached indefinitely, since it can not change anymore.
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.
According to http://msdn.microsoft.com/en-us/library/ff823993%28v=VS.85%29.aspx, during this event the web filter can request GUID of the matching rule. I am assuming that is done by performing a GetServerVariable with type of SELECTED_RULE_GUID, since I could find no other readily identifiable means of doing so.
My problem comes from the fact that I want to see if the rule is allowing or blocking the request. If it's being blocked then my filter doesn't have to take any action, but if it's being allowed I need to do some work. SF_NOTIFY_POLICY_CHECK_COMPLETED seems to be the best event to watch, since it occurs last enough that authentication and various ms_auth traffic has been handled, but just before the request either gets routed or fetched from cache.
I had thought that perhaps I needed to use COM and the IFPC interfaces (following along with example code for registering Web Filters to TMG) to get details on the rule. However, going down via FPC -> FPCArray -> FPCArrayPolicy -> FPCPolicyRules, the only element-returning function takes either an index or a name.
Which is problematic given that I only have a GUID.
The FPCPolicyRule object (singular) doesn't seem have any field related to GUID either, which eliminates just iterating over the collection for it.
So my question boils down to, from the SF_NOTIFY_POLICY_CHECK_COMPLETED event, how would a web filter determine if the request has been allowed or denied?
After more investigation and testing, the GUID is accessible via the PersistentName of the FPCPolicyRule object. Since FPCPolicyRules->Item member only works on either Name or Index, I had to iterate through its items comparing each PersistentName against the GUID.
Apologies if this was obvious, took me a good day to work out :)