Request.Cookies and Response.Cookies both contain a collection of HttpCookies, however, the usage of the Cookie object differs in each. For example, the value contained in Request.Cookies["MyCookie"].Expires seems to be useless, since browsers don't actually send the expiration date back to the server with the request. But since this field exists, it causes a lot of confusion with developers assuming the field has meaning, trying to use it, and then inevitably searching to find out why the expiration date is always 1/1/0001. There are other unused fields as well when looking at a cookie in the Response vs the Request because they are used in different ways, so I wonder:
What are the potential design reasons why a single class (HttpCookie) is used for both a request cookie and a response cookie, given the usage concerns noted above?
Edit: I see some people have voted to close this question because it is too opinion based. Someone certainly might know the answer to this, e.g. it was designed this way because of X. I would also be interested in knowing someone's best guess too, if no one outside of MS knows what X is.
Edit 2: Another valid answer would be that it was probably an oversight and they should be different objects.
I never found this in my original searching, but I'm guessing Anthony's response to this question is probably the best I'm going to get. He proposes:
Strictly speaking .NET ought to have used two different types (RequestCookie and ResponseCookie) but instead chose to use the same type for both circumstances.
I'll happily accept an answer that offers valid reasons (or conjecture) for why that choice was made, if it was intentional.
Related
I was presented with this argument when fixing a bug related to implicit casting and speaking to the developer who told me:
If you use Closure, then you do not need absolute equality. Any value would be typed, therefor you don't need to worry about implicit casts.
My response was, that's dicey. You're making a lot of assumptions; Closure does not alter JavaScript, it's primarily a labyrinthine super layer (aside: probably a moot one, now that we have TypeScript).
Anyway, if one of these implicit things does slip by because the annotations don't resolve perfectly for some reason, you can end up with a tough bug (which is what happened; it got assigned to me because I guess the other dev didn't think it could be the problem).
I got responses of, "well if that dev had properly typed that object and this wasn't just an object and..."
Or...you could just protect against this sort of thing easily by using three equal signs instead of two. Use an assertion or console log to check the condition if necessary. Don't just leave it hanging out there.
Anyway what do you think; if you're using Closure, should you still observe the general best practice of using absolute equality in your JS code?
I know this leads to a wider conversation as well (e.g. Java 8's "optional" being "totally useless"), curious in the context of Closure though.
Question is a bit vague, code example would have helped. But yes, closure does not necessarily type every object and variable. I always use === unless there is a specific reason not to.
Since the headers needed to iterate the posted event list in QCoreApplication::compressEvent are considered private, is there a way of getting equivalent functionality without depending on Qt's internal headers, but only on documented semantics of Qt?
Note that this is a different question that the other one concerning signals and slots!
Since the headers needed to iterate the posted event list in QCoreApplication::compressEvent are considered private, is there a way of getting equivalent functionality without depending on Qt's internal headers, but only on documented semantics of Qt?
AFAIK, there is not as per my other post.
The only API for this is internal as you write, and it can change anytime without further notice. Thereby, unless someone is writing code being part of the Qt release, this should be avoided since it can break all of a sudden for end users.
I even discussed it with 1-2 developers on IRC (peppe and suy, I think), but I think we left the topic at that point that there is no public API. This may change in the future as noted in the post.
My personal suspicion, without talking to the maintainer about it, is that it has not been a common enough use case, and hence no one has bothered just yet to get it through. I could personally live without this feature on since it has not caused me any serious defect so far, even in large scale Qt based and heavily multi-threaded softwares.
It is also quite possible that there may be technical reasons behind, and it is just my ignorance.
Who says RESTful APIs must support partial updates separately via HTTP PATCH?
It seems to have no benefits. It adds more work to implement on the server side and more logic on the client side to decide which kind of update to request.
I am asking this question within the context of creating a REST API with HTTP that provides abstraction to known data models. Requiring PATCH for partial updates as opposed to PUT for full or partial feels like it has no benefit, but I could be persuaded.
Related
http://restcookbook.com/HTTP%20Methods/idempotency/ - this implies you don't have control over the server software that may cache requests.
What's the justification behind disallowing partial PUT? - no clear answer given, only reference to what HTTP defines for PUt vs PATCH.
http://groups.yahoo.com/neo/groups/rest-discuss/conversations/topics/17415 - shows the divide of thoughts on this.
Who says? The guy who invented REST says:
#mnot Oy, yes, PATCH was something I created for the initial HTTP/1.1 proposal because partial PUT is never RESTful. ;-)
https://twitter.com/fielding/status/275471320685367296
First of all, REST is an architectural style, and one of its principles is to leverage on the standardized behavior of the protocol underlying it, so if you want to implement a RESTful API over HTTP, you have to follow HTTP strictly for it to be RESTful. You're free to not do so if you think it's not adequate for your needs, nobody will curse you for that, but then you're not doing REST. You'll have to document where and how you deviate from the standard, creating a strong coupling between client and server implementations, and the whole point of using REST is precisely to avoid that and focus on your media types.
So, based on RFC 7231, PUT should be used only for complete replacement of a representation, in an idempotent operation. PATCH should be used for partial updates, that aren't required to be idempotent, but it's a good to make them idempotent by requiring a precondition or validating the current state before applying the diff. If you need to do non-idempotent updates, partial or not, use POST. Simple. Everyone using your API who knows how PUT and PATCH works expects them to work that way, and you don't have to document or explain what the methods should do for a given resource. You're free to make PUT act in any other way you see fit, but then you'll have to document that for your clients, and you'll have to find another buzzword for your API, because that's not RESTful.
Keep in mind that REST is an architectural style focused on long term evolution of your API. To do it right will add more work now, but will make changes easier and less traumatic later. That doesn't mean REST is adequate for everything and everyone. If your focus is the ease of implementation and short term usage, just use the methods as you want. You can do everything through POST if you don't want to bother about clients choosing the right methods.
To extend on the existing answer, PUT is supposed to perform a complete update (overwrite) of the resource state simply because HTTP defines the method in this way. The original RFC 2616 about HTTP/1.1 is not very explicit about this, RFC 7231 adds semantic clarifications:
4.3.4 PUT
The PUT method requests that the state of the target resource be created or replaced with the state defined by the representation enclosed in the request message payload. A successful PUT of a given representation would suggest that a subsequent GET on that same target resource will result in an equivalent representation being sent in a 200 (OK) response.
As stated in the other answer, adhering to this convention simplifies the understanding and usage of APIs, and there is no need to explicitly document the behavior of the PUT method.
However, partial updates are not disallowed because of idempotency. I find this important to highlight, as these concepts are often confused, even on many StackOverflow answers (e.g. here).
Idempotent solely means that applying a request one or many times results in the same effect on the server. To quote RFC 7231 once more:
4.2.2 Idempotent methods
A request method is considered "idempotent" if the intended effect on the server of multiple identical requests with that method is the same as the effect for a single such request.
As long as a partial update contains only new values of the resource state and does not depend on previous values (i.e. those values are overwritten), the requirement of idempotency is fulfilled. Independently of how many times such a partial update is applied, the server's state will always hold the values specified in the request.
Whether an intermediate request from another client can change a different part of the resource is not relevant, because idempotency refers to the operation (i.e. the PUT method), not the state itself. And with respect to the operation of a partial overwriting update, its application yields the same effect after being applied once or many times.
On the contrary, an operation that is not idempotent depends on the current server state, therefore it leads to different results depending on how many times it is executed. The easiest example for this is incrementing a number (non-idempotent) vs. setting it to an absolute value (idempotent).
For non-idempotent changes, HTTP foresees the methods POST and PATCH, whereas PATCH is explicitly designed to carry modifications to an existing resource, whereas POST can be interpreted much more freely regarding the relation of request URI, body content and side effects on the server.
What does this mean in practice? REST is a paradigma for implementing APIs over the HTTP protocol -- a convention that many people have considered reasonable and is thus likely to be adopted or understood. Still, there are controversies regarding what is RESTful and what isn't, but even leaving those aside, REST is not the only correct or meaningful way to build HTTP APIs.
The HTTP protocol itself puts constraints on what you may and may not do, and many of them have actual practical impact. For example, disregarding idempotency may result in cache servers changing the number of requests actually issued by the client, and subsequently disrupt the logic expected by applications. It is thus crucial to be aware of the implications when deviating from the standard.
Being strictly REST-conform, there is no completely satisfying solution for partial updates (some even say this need alone is against REST). The problem is that PATCH, which first appears to be made just for this purpose, is not idempotent. Thus, by using PATCH for idempotent partial updates, you lose the advantages of idempotency (arbitrary number of automatic retries, simpler logic, potential for optimizations in client, server and network). As such, you may ask yourself if using PUT is really the worst idea, as long as the behavior is clearly documented and doesn't break because users (and intermediate network nodes) rely on certain behavior...?
Partial updates are allowed by PUT (according to RFC 7231 https://www.rfc-editor.org/rfc/rfc7231#section-4.3.4).
",... PUT request is defined as replacing the state of the target resource." - replacing part of object basically change state of it.
"Partial content updates are possible by targeting a separately identified resource with state that overlaps a portion of the larger resource, ..."
According to that RFC next request is valid: PUT /resource/123 {name: 'new name'}
It will change only name for specified resource. Specifying id inside request payload would be incorrect (as PUT not allow partial updates for unspecified resources).
PS: Below is example when PATCH is useful.
There is object that have Array inside. With PUT you can't update specific value. You only could replace whole list to new one. With PATCH, you could replace one value to another. With maps and more complex objects benefit will be even bigger.
HttpContext.Current.Items["ctx_" + HttpContext.Current.GetHashCode().ToString("x")]
I see this exact code all ... over ... the ... place but I must be overlooking something. It's common in responses to these posts to question the appropriateness of using HttpContext, but no one points out that GetHashCode is redundant and a fixed string will do.
What am I overlooking here?
EDIT: The question is, GetHashCode() will be the same for every HttpContext.Current, so why use GetHashCode() in the four links I provided? Some of them are posts with quite a bit of work put into them, so I feel like perhaps they are addressing some threading or context issue I'm overlooking. I don't see why just HttpContext.Current.Items["ctx_"] wouldn't do exactly the same.
This is horrible. For one, HttpContext.Current.Items is local to the current HttpContext anyway so need to attempt to make the keys "more unique". Second, depending on how this technique is used the keys will collide once in a while causing spurious, undebuggable failures.
If you need a unique key (maybe because you are developing a library), use a saner solution like Guid.NewGuid().ToString(). This is guaranteed to work and even simpler.
So to answer your question :)
It doesn't make much sense to use GetHashcode for creating key.
Authors of posts you gave links to probably wanted to create key that will be unique. But doing this doesn't stop other team member to use same key somewhere else in the code base.
I think it's better to just use handwritten long keys. Instead of
["ctx_" + HttpContext.Current.GetHashCode().ToString("x")]
just use
["object_context_key"]
or something like that. That way you know what it is exactly (and that may be usefull in for example post mortem debugging) and I also think that if you have to come up with some long key it is possible that it will be 'more unique' then the one with GetHashCode.
The verbs are pretty straightforward for CRUD actions.
What would be the right HTTP verb for only performing an action, something
like an upvote?
Maybe this speaks more to data modeling? Is an upvote a resource or just an attribute? I'm unsure about that. Let's say it does modify the resource directly by calling #upvote on the model.
For example, if I upvote a question here on SO, what verb should be ideally used for that action? I am modifying the resource in a partial manner (PATCH?), but at the same time, I don't want to specify the new value as I could encounter concurrency issues, so this would best be managed by the database. In other words, we want to ask the server to perform an incremental action on a resource. Is that covered by PATCH?
I've seen a similar question asked there, but their case pointed to the creation of a new resource by viewing the job request as an object to be created. Are we in the same case here?
If the PATCH method really would be appropriate, what would it contain?
Maybe this speaks more to data modeling? Is an upvote a resource or just an attribute?
Modelling impacts Implementation
We are usually modelling something from the real world and our choice of representation will seriously affect the capabilities of the developed system. We could implement our vote in two ways: as an attribute on the thing being voted on or as an entity in its own right. The choice will affect how easily we can implement desired features.
Two possible implementations ...
1. Votes as entities
I would model this with a resource which modelled the relationship between the voter and the thing being voted on. Why?
The vote has state:
what was being voted on
who voted,
when did they vote.
was it an up vote or a down vote (you mentioned SO as an example so I include that possibility here)
It is a resource in its own right with interesting behaviour around the votes
maintain a correct count of the votes
prevent multiple up votes / down votes
It can be modelled easily with REST.
I can POST/PUT a new vote, DELETE a previous vote, check my votes with a qualified GET.
The system can ensure that I only vote once - something which would not be easy to do if a simple counter was being maintained.
2. Votes as an attribute
In this implementation, we model the vote as a counter. In this case we have to
Get the entire state of the thing being voted on - maximising the interface between client and server
Update the counter
Put back the updated state - oops, someone already updated the
resource in the meantime!
The server now has no easy way to handle multiple votes from the same person without managing some state 'on the side'. We also have that 'lost update' problem.
Things quickly get complicated.
Final advice
The decision on how you model something should be driven by what you need the system to do.
There is often no correct decision, just the best compromise between effort and value.
Choose a design which most easily implements the most common Use Cases. Common things should be quick and simple to do, uncommon things need only be possible.
Chris