I realize this might sound like an odd question, but I'm seeing some odd results in my network calls so I'm trying to figure out if perhaps I'm misunderstanding something.
I see situations where in isolated incidents, when I'm uploading data, even though the response is 200, the data doesn't appear on the server. My guess is that the 200 response arrives during the initial HTTP handshake and then something goes wrong after the fact. Is that a correct interpretation of the order of events? Or is the 200 delivered once the server has collected whatever data the sending Header tells it is in the request? (cause if so then I'm back to the drawing board as to how I'm seeing what I'm seeing).
It means it has been successfully finished. From the HTTP /1.1 Spec
10.2.1 200 OK
The request has succeeded. The information returned with the response is dependent on the method used in the request, for example:
GET an entity corresponding to the requested resource is sent in the response;
HEAD the entity-header fields corresponding to the requested resource are sent in the response without any message-body;
POST an entity describing or containing the result of the action;
TRACE an entity containing the request message as received by the end server.
Finished. It doesn't make sense otherwise. Something might go wrong and the code could throw an error. How could the server send that error code when it already sent 200 OK.
What you experience might be lag, caching, detached thread running after the server sent the 200 etc.
A success reply, like 200, is not sent until after server has received and processed the full request. Error replies, on the other hand, may be sent before the request is fully received. If that happens, stop sending your request.
Related
I have a DB table with a report_url column. As soon as a backend done with filling and storing a report it fills that column with S3 link. If the report was not yet stored, the column value is NULL by default. I also have Pyramid API where an endpoint is declared returning Response with body of report content. So, whenever the user makes request, according controller will be fired to get the report link and download the file and return it to user. However, if report is not done yet (report_url is NULL), I need to inform the user somehow. In this case front-end should receive HTTP status 400, but I have not figured out if this fits best. Or maybe 503 fits better here?
Have a look at available http status codes.
What you probably want is 404, specifically because of this line:
In an API, this can also mean that the endpoint is valid but the
resource itself does not exist.:
Full description:
404 Not Found
The server cannot find the requested resource. In the browser, this
means the URL is not recognized. In an API, this can also mean that
the endpoint is valid but the resource itself does not exist. Servers
may also send this response instead of 403 Forbidden to hide the
existence of a resource from an unauthorized client. This response
code is probably the most well known due to its frequent occurrence on
the web.
If the server is working on getting the report, 102 gets an honorable mention:
102 Processing (WebDAV)
This code indicates that the server has received and is processing the request, but no response is available yet.
it's not part of the standard, it's an extension, WebDAV.
400 status codes are used to let the user know something they did is not working. 500 status codes are used when something is going on with the server. That's how I understand it anyway.
In that way, if this is a "normal" execution of the API/program, perhaps a 200 status code would do just fine. E.g. just define the endpoint to return {"report_url": null} if it isn't ready, otherwise {"report_url": "an actual url"} and then give 200 in each case. And the receiving party handles it depending on if it is null or not. The pro of this method is, now the user can know that it is definitely a proper endpoint (and not an url typo, which would also give 404). However, you could make your own 404 page saying "report is not ready" or "report does not exist" for example. The con of this 200 method is some speed penalty since you have to send an unnecessary response body.
Disclaimer: I am not a web/http expert at all.
The correct HTTP status code is 202 - Accepted. The documentation says:
The 202 (Accepted) status code indicates that the request has been accepted for processing, but the processing has not been completed.
..
The representation sent with this response ought to describe the request's current status and point to (or embed) a status monitor that can provide the user with an estimate of when the request will be fulfilled.
In my API, I am processing an object which contains a DSL script which can fail syntax/type validation, however I'll still persist the object regardless of any parsing failure, and send back the persisted object along with the failure messages. However, I am having trouble choosing the right HTTP status code to characterize this condition.
From my StackOverflow research:
HTTP 400 seems inaccurate since the request was not malformed and could be processed.
HTTP 202 seems promising but there isn't really async processing happening.
HTTP 422 is popular in other SO posts though I've never seen it used in practice.
Is sending an HTTP 200 still appropriate in this scenario since nothing really "failed"? Is there a more appropriate HTTP code to use here?
Any 4xx status should imply that the server did nothing, and the state did no change. Therefore, a 2xx code is the most appropriate.
You could use the Warning header:
http://greenbytes.de/tech/webdav/rfc7234.html#header.warning
I send some values using spring httpClient to other url. And about that question as I know if I send name=mister age=30 values, received page get that values not http status values, right?
Http status values are for sending page's not receive page's.
I mean, if I send those values, receiving page gets http values.
If receiving page want to get that values, I have send that values, is that right?
My team manager said to me that http has request and response so, if you send some values to other url, other url gets http status values.
But as I thought that is little bit anyway I can't understand my team manager's saying, please let me know, receiving page gets http status when I send some values.
Your team manager's statement is correct. ("the http status have to be written.", "http has request and response. so there should have that http status value result"). What he/she mentioned is HTTP response status code, which should be returned (with correct code) whatever the response is.
No matter your result (name=mister and age =30 etc.) is a static page or an Ajax response, the response code should be 200 OK when the result is generated successfully (correct business logic, no error happens). But when something bad happens, it is important to let client know why server failed to return result -- maybe it is because the request format is incorrect (400 Bad Request), there is a typo in request url (404 Not Found) or some error in server code (500 Internal Server Error). Send name=null and age=null to client with 200 OK is incorrect and bug prone. Without definition of these error status code in document, backend engineer have to communicate with frontend engineer during the development, API by API, case by case, which is very time consuming and inefficient.
I think your TODO is: for the API that accepts name=mister and age =30, define success case and different failure case, then assign correct response code to them.
I've poked around a bit, but I don't see an HTTP status code for when a request's succeeds, but there is an error after the "point of no return".
e.g., Say you process a request, its committed to the database, but while returning the result you run of memory, or encounter a NPE, or what have you. It would have been a 200 response, but now, internally, you aren't able to return the proper, well-formed response.
202 Accepted doesn't seem to fit since we've already processed the request.
What status code means "Success, but errors"? Does one even exist?
HTTP doesn't have such a status code, but there is a best practice that allows you to handle such situations - redirect the user after a POST operation.
Here is a break down -
A POST request tries to modify data on the server
If the server fails, it sends a 500 error to indicate failure
If the server succeeds, it sends a 302 redirect response
The browser then sends a fresh GET request to the server
If this fails, you get a 500 error, otherwise you get a 200
So, your use case of 'Saved data but can't retrieve it immediately' translates to a 302 redirect for the initial POST, followed by a 500 for the subsequent GET.
This approach has other advantages - you get rid of the annoying 'Are you sure you want to resubmit the data?' message. Also keeps your back/forward/refresh buttons usable.
If the server is aware that it has encountered a problem, it should normally return a 5xx error. The most generic one is the 500 Server Error, which the RFC 2616 defines as follows:
500 Internal Server Error
The server encountered an unexpected condition which prevented it
from fulfilling the request.
Then it's the client's responsibility to reattempt the request. If the previous request was partially committed, it's the server's (or the database's) responsibility to roll that back, or to handle the duplicate transaction appropriately.
I agree with #Daniel that the proper response is an HTTP 500 (server error). The web application has to be written to roll back the transaction when there is an error, not leave things half-finished.
One thing you can leverage in your web application is "idempotency". This is the property of a function (or operation) that you can repeat it as many times as you like with the same result. For instance if a read fails, the client can simply retry it until it succeeds. If a deletion appears to fail, the client can again retry and the server will treat the request as valid whether or not the resource being deleted is already gone. And if an update appears to fail, the client can retry that until it gets a successful return from the server. The REST approach to architecting web services makes heavy use of idempotency to make operations robust in the face of error.
We have a REST API which clients routinely POST and PUT data to. When they do this, sometimes they POST data which results in no change on our system. The POSTs and PUTs are well-formed, but they data they're sending is identical to the data in our database. When this happens, I've just found out that we're returning a 400 HTTP status. Unfortunatly, this means "bad request" as in "request could not be understood by the server due to malformed syntax".
Clearly this is not the case, but I'm told that we're going to use this since there's no other appropriate status code. Choices we've considered:
304 Not Modified. This, regrettably, is only for GET requests.
204 No Content. Seems close, but forbids an entity-body.
Other choices seem equally bad. We might go with 200 OK and have the relevant information in the XML document we return, but this doesn't seem very "RESTish". How does the REST world generally handle this?
(Fixed Not Modified response code. Thanks Mkoeller)
I think it's perfectly fine to return a 200 OK in that case, the data was correctly processed and the server did what it had to. Because the server processed correctly the data, it should return an OK status code. The fact that it ignored it internally is or should be irrelevant.
What the server did to the data should not be told to the clients, they should be told what happened to the request (processed ok, error occurred, and the like).
And if, for some weird reason (I can't think a valid one, btw), it is of interest to the clients, you have the response to tell them so.
If the clients are able to know the entity tag for the content on the server before they PUT, then using If-Match headers and the 412 Precondition Failed response exists for exactly the situation you describe.
From client view the server status is the same if the request content was the same on the server or not, right? Since the server afterwards holds excactly the content that was sent, why should the server respond with any kind of error status?
On the other hand why should the client bother if the request content was the same as already known to the server? It was successfully transfered to the server so the bulk of work is done. How is a client expected to react if there was a different response code for this situation?
Conclusion: Your situation of a request content equaling the existing content is no special case. You should respond with the same response status code. That might be 200, 302 or 303.