I am getting below error when response is larger in size, We can fix below by enabling Streaming in Apigee ( Currently out of scope as needs work at all up streams)
The error pasted below: {"Envelope":{"Body":{"Fault":{"faultcode":"soap:Server","detail":{"source":{"errorcode":"protocol.http.TooBigBody"}},"faultstring":"Body buffer overflow","faultactor":{}}},"encodingStyle":"http:\/\/schemas.xmlsoap.org\/soap\/encoding\/"}
I am planning raise fault when we get above error from downstream system. What should be HTTP Status Code ?
413 Request Entity Too Large
400 "Message: Response is large"
My vote is for 500 - Internal Server Error, with some detail in the body. A 4xx error code indicates to the client that they should retry the request after making some modifications. That does not seem to be the case here.
Well, it looks like it should be a 500 error. And, as a good practice, you should add some details in the body or a good and clear message, as said before by some wise people here.
All the 4xx errors indicates that the system is fine but your request is not. Some examples:
400: will not process the request due to a client error. In the past this code was only for syntax error, but nowadays is more generic: https://www.rfc-editor.org/rfc/rfc7231#section-6.5.1
403: indicates that the server understood the request but refuses to authorize it.
415: the payload format is not supported
422: the request format and syntax are ok, but the server will not process it. Normally a good one to raise when validation fails or some semantics are not correct. More: https://www.rfc-editor.org/rfc/rfc4918#section-11.2
You can check all RFCs you want and will not find a 4xx error for this situation. Unless you misexplained and the user should change the request in any way in order to get the right result. In this case, 422 could be your choice, for example, if the request is in the right format and syntax, but the user is requesting too many resources.
If you will/can not do anything to return a response with expected body attributes to the clients in this case, then you should return 500 with a good message.
I saw services return 200 and the details of the issue at some part of the response with a good (okay) message as errorMessage or something in similar cases.
The idea here is to propagate the exception so that the client app can give a proper message to the end users, so let the client application know about the issue with the message.
HTTP 413 Payload Too Large is wrong status code for this situation because it tells to the clients that you are sending large request and it leads to confusion of them.
HTTP 400 Bad Request is wrong status code for this situation because the request is correct and server knows what it wants to get but because of its own limits, server doesn't want to answer to this amount of response size.
HTTP 403 Forbidden should be your choice.
The server understood the request, but is refusing to fulfill it.
Note, mostly it is a good idea to tell the reason of refusing the request with correct response status code and custom message.
If I understood your question correctly, Your API server is not able to full fill the request it got because the response for the request is too large.
In this case, We should be returning 503 - Service Unavailable. This way we can indicate that our API server not able to respond to the request temporarily, It's not a complete downtime of the API server and it's not happening for all the requests at a time which we got. This is gonna happen only when the response/payload is too large and that too for the selective requests. Since our API server is not able to handle and respond to the request at that moment it should be.
Related
If a web application returns an HTTP 4xx response back to the client should the client assume that the communication was stateless? If this is true, should web applications return a 5xx response in the case where a client's request results in a state change but further processing fails due to an issue with the client's request (we can assume that top layer validation cannot detect this case and recovery is not possible).
Is there an ISO standard developers can refer to that discusses what is expected as far as application state is concerned when an HTTP 4xx is returned? Is this covered in RESTful architecture?
So, working backwards -- the semantics of 5xx response messages and 4xx response messages provide the same guarantees about changes to resource state.
For instance, HTTP caches will treat both 4xx and 5xx as an "error response".
HTTP standardizes the meanings (semantics) of HTTP response codes, but it doesn't constrain implementations - your server is free to return whatever message you want, so long as you describe the message you return appropriately.
If you are expecting general purpose clients to understand that there was a problem with the request itself; then you should normally choose to respond with a representation that explains the actual problem, and use the correct HTTP meta data (including the response code) so that intelligent clients can do useful things.
The fact that your server actually did some work that changed the state of the exposed resources is "just" an implementation concern. There's fundamentally no difference between the case you describe, and the case where this request had no effect, but some other request to the server made changes that this client doesn't know about (yet).
If you want the general purpose client to understand that the resource has changed (and that previously cached responses should no longer be used), then you need to return a response with a non-error status code.
At a higher level, the important idea to understand is that a REST API is a facade - it provides the illusion that our sophisticated service is "just" an HTTP compatible document store.
I have long operation, which called via Web API. Status code 102 says to us:
An interim response used to inform the client that the server has
accepted the complete request, but has not yet completed it.
This status code SHOULD only be sent when the server has a reasonable
expectation that the request will take significant time to complete.
As guidance, if a method is taking longer than 20 seconds (a
reasonable, but arbitrary value) to process the server SHOULD return a
102 (Processing) response. The server MUST send a final response after
the request has been completed.
So, I want to return 102 status code to client, then client waits response about result of operation. How to implement it on .NET?
I read this thread: How To Return Http 102 Processing in Asp.Net Web Api?
This thread has good explanation what is necessary, but no response. I don't understand how it implement on .NET, not theory...
Using HTTP 102 requires that the server send two responses for one request. ASP.NET (Core or not) does not support sending a response to the client without completely ending the request. Any attempt to send two responses will end up in throwing an exception and just not working. (I tried a couple different ways)
There's a good discussion here about how it's not actually in the HTTP spec, so implementing it isn't really required.
There are a couple alternatives I can think of:
Use web sockets (a persistent connection that allows data to be sent back and forth), like with SignalR, for example.
If your request takes a long time because it's getting data from elsewhere, you can try pulling in that data via a stream and send it to the client via a stream. That will send the data as it's coming in, rather than loading it all into memory first before sending it. Here's an example of streaming data from a database to the response: https://stackoverflow.com/a/45682190/1202807
Suppose I have an endpoint that supports creating new messages. I am avoiding the creation of two times the same message in the backend, in case the user tries to push the button twice (or in case the frontend app behaves strangely).
Currently for the duplicate action my server is responding with a 303 see other pointing to the previously created resource URL. But I see I could also use a 302 found. Which one seems more appropriate ?
Note that the duplicate avoidance strategy can be more complex (eg for an appointment we would check whether the POSTed appointment is within one hour of an existing one)
I recommend using HTTP Status Code 409: Conflict.
The 3XX family of status codes are generally used when the client needs to take additional action, such as redirection, to complete the request. More generally, status codes communicate back to the client what actions they need to take or provide them with necessary information about the request.
Generally for these kind of "bad" requests (such as repeated requests failing due to duplication) you would respond with a 400 status code to indicate to the client that there was an issue with their request and it was not processed. You could use the response to communicate more precisely the issue.
Also to consider, if the request is just "fire and forget" from the client then as long as you've handled the case for duplication and no more behavior is needed from the client it might be acceptable to send a 200 response. This tells the client "the request was received and handled appropriately, nothing more you need to do." However this is a bit deceptive as it does not indicate the error to the client or allow for any modified behavior.
The JSON:API specification defines:
A server MUST return 409 Conflict when processing a POST request to create a resource with a client-generated ID that already exists.
I have an RESTful API that calls another remote webservice. In general I have to query this remote service for every request that comes to my specific API function, and in my code I am wrapping and/or modifying parts of the result.
However it is possible that this remote service is not answering in time or throws an error. What is the most logical response that my API should throw then? I am specifically thinking about:
HTTP 500 - however this gives the client no information what is happening
HTTP 503 with a Retry-After header - then the client clearly sees this is an error and can query again later
HTTP 200 and returning an empty result
HTTP 200 and returning an error message or something like that
...or doing something completely different?
It all depends on what you want your API to convey to your client.
500: client cannot fetch his resource and does not know whether he should just bombard your server with another request, but at least knows it MIGHT exist
503: client cannot fetch his resource, but at least knows it MIGHT exist and can retry later in X amount of time.
200 *Empty response*: client is told his resource is empty and everything is ok, so probably will not come back while the resource could be not empty and was available a second later (Kind of misleading).
200 *Error message*: client is told everything is ok, but receives in your context an error message. (This is wrong and totally contradicting itself/yourself!)
My advice:
Do the 503
I am building an Air application that long-polls a Spray server to get relevant updates.
I am new to Spray and have read that, if requests are not handled on time, a 500 timeout error is automatically sent to the client by the framework. I can catch this error on the Air side, and then send another request, etc.
Are there any drawbacks to using this approach (I cannot think of any) or is it better to avoid the timeout and send back some sort of "no news" message to the client instead?
I would say, from a RESTful perspective, that the response should pertain to the state of the resource. Looking at the available response codes:
204 No Content The server successfully processed the request, but is
not returning any content.
This states that the request was carried out successfully yet there is nothing to return.
204 No Content