I don't know if it ever would, but if my server responded with HTTP status code 304, would the Fetch API (specifically response.ok) and axios.get() see the response as 200?
The documentation for both talk about the request being viewed as successful if the response code is in the range 200-299, but clearly 304 is outside this.
When a browser does a GET request with a If-Match or If-Modified-Since header, and the server responds with 304 Not Modified, the client will just see this as 200 OK.
The response is served from cache, instead of the server, and it allows the client (axios in your case) to not have to understand HTTP caching, but it can still take advantage of it.
I don't know what a client will do when they send a request without preconditions and still get a 304 response. A client wouldn't have an earlier cached response so this would definitely be 'broken'. I'd imagine you'd get an error but I'd be curious to see what.
No, they will both not see the response as 200.
While axios.get will return a promise rejection, the return value of response.ok when using fetch API will be false and response.redirected will be true.
Related
I am setting cachePolicy on url request.
First call to an url (GET) return status code in 200.
Second call to the same url return 200.
If use a rest client i obtain for the first call 200, and for the second, with properly header ( If-None-Match) 304
Reading online i understand that iOS serialize first request with status code 200 and retrieve it for the second call.
There is a way to obtain 304 instead of 200 in UrlCache or understand if it the data came from cache and not from network.
From http://jonathanblog2000.blogspot.com/2017/07/ios-uiwebview-nsurlsession-cache.html :
If you want to test and verify the cache works properly in your app, you have to log the device http traffic, as the delegate of NSURLSession will never see the 304 status code returned from server, it will be automatically replaced by the status code in the cached response.
This is a good thing. This means your app can just pretend you got a successful response, and not worry about how the response was obtained or what sort of optimizations was happening. You just deal with the response the same way regardless of whether it was pulled from the cache or not.
I am specifically interested in whether a proxy server(or other http caches) caches the URI, Method, Headers and Body of the client's request? Or is it only URI and Method?
The reason is I am confused with negative caching, e.g. caching response with 400 status code ("Bad request"). I mean if the first response had an "invalid" body that caused the 400 error and we cache it does it mean that subsequent requests with a "valid" body will still get 400 response from the cache? (Without even hitting the Origin server?
The GET requests are the ones that can be cached by intermediary caches.
As shown in the book "HTTP: The definitive guide" only URL and headers get cached.
The PUT, POST and DELETE requests will cause the cache to be invalidated as shown here.
So my original question (about 400 response because of invalid body) was wrong since GET request should not have body according to REST and other methods (which could have body) cause the cache to be invalidated.
Thanks #Adrien for pointing at it!
I have a request from the client - when the user performs an action, there can be 3 actions:
the action succeeds with 200 OK status
the action fails (400) with an error message
the action succeeds but we need to display a helpful warning message to the user. This happens when the allocated amount is almost used up.
There does not seem to be a way for REST APIs to return an indication that the action completed successfully with some helpful information that further action might fail.
Thanks
HTTP response codes are limited and I think, those to be used to indicate any generic response. To have application specific response codes or response strings, it is better to have application level response codes to be communicated via HTTP response payload.
You didn't mention which HTTP method you are preparing for. Using GET should of course not modify anything, so I'm assuming it's either POST or PUT.
For POST, the response should be 201 Created. There should be a Location header line indicating the resource that was created.
For PUT, the response should be 200 OK.
In both cases, you can return a content body, as others suggested. This body can be some status information about the current state of whatever resource you are using. Note, that this status information might be reachable explicitly by some other URI, so it can share a mime-type with that "status" resource.
REST is using HTTP methods and HTTP status to represent the status of reply, by checking HTTP status I can find code 203 I think it could be suitable for your 3rd case :
203 Non-Authoritative Information (since HTTP/1.1)
The server successfully processed the request, but is returning information that may be from another source.
A PUT requests can have many outcomes, and I was wondering which status code would be best for each of them.
Say I want to create a new resources, so I do something like that:
PUT http://example.com/resources/resource-1
And I would get a HTTP 201 because a new resource has been created.
Now I want to update this resource, so I do the same request, with new contents:
PUT http://example.com/resources/resource-1
And I get HTTP 200 or HTTP 204, because the resource has been updated. But what if I send this request once again with the same contents? Should the server return HTTP 200 or HTTP 204 even if nothing has been updated?
I am aware that HTTP 200 and HTTP 204 both just mean that the request was successfully processed, and even if the data don't change the request can (and should) still be successfully processed. But is there a way to tell the client that the request has been successfully processed but nothing has changed on the server side? And if there is, should it be used for a PUT request? PUT being idempotent, should different status be returned depending on the actual processing on the server side (as long as no error occurs during this processing)?
But is there a way to tell the client that the request has been successfully processed but nothing has changed on the server side?
Yes, but that's not what status codes are for.
Either return 200 OK and a representation of the entity, or 204 No Content and return nothing.
For no change being applied, use a header like ETag. The client can compare the ETag with their previous value, and determine nothing was changed.
If I want to return a status code of 303 See Other when a client POSTs data that already exists, am I allowed to return that data in the content (body) of the response (in addition to setting Location), or must the client then GET the Location?
I would like to avoid requiring the client HTTP to make two HTTP calls if at all possible.
Idiomatically, the client should retrieve the data with a GET request.