How to add the unhandled exceptions accross the applications in response body in WEB API. If there is no exceptions a success message needs to be sent to the response body for all the responses....Need help on achieving this.
You need two things. For handling the exceptions, you need to set the IncludeDetailErrorPolicy in the HttpConfiguration object,
You can configure the error policy preferences as part of the configuration object (HttpConfiguration) in the IncludeErrorDetailPolicy property. This is just an enum that instructs Web API about how to deal with exceptions.
The possible values for this enum are,
Default: It’s uses the customErrors configuration settings if you are using ASP.NET as host or LocalOnly for self-host.
LocalOnly: Only includes error details for local requests
Always: Always includes error details
Never: Never includes error details
When an exception happens, Web API will check the value on this setting for including details about the exception in the response message or not. For example, if Always is enabled, Web API will serialize the exception details as part of the message that you get as response.
The success message does not make much sense as you already have the response status code. A status code equals to OK means that everything went ok. If you still want to add an additional message, use a HttpMessageHandler that checks for the response status code. If the status code is OK, add the message. However, the response body has been set already at that point so you will not able to modify it. You might able to add a message as a header.
Related
Is there any way to get the response body in Azure Logic App even when we get 500 Internal Server Error?
I have made the Logic App in a way that I'm setting the response code to 500 on an issue, and I'm adding some error related information in the response body. I tried returning 504 Gateway timeout as well, in case of a timeout issue I could face, but I'm always receiving a null response body in case of non-200 response codes.
If we are not able to see the response body in case of an error by design, is there a better way to set and fetch error related information from the response object?
Yes you can get the response body in Azure Logic App by adding the response action. According to this Add a Response action section of the Microsoft document.
When you use the Request trigger to handle inbound requests, you can model the response and send the payload results back to the caller by using the built-in Response action.
Following steps would help you to get the response body.
In the Logic App Designer, under the step where you want to add a Response action, select New step.
The under Choose an action, in the search box, enter response as your filter, and select the Response action.
Now add any values that are required for the response message. For the Body, you can select the trigger body output from the dynamic content list.
I would suggest to read the Receive and respond to inbound HTTPS requests in Azure Logic Apps document for more information.
Alternatively you can also create alerts whenever HTTP 500 errors occur in your App and use Application Insights to view it using Azure Monitor. I would also suggest to read this Handle errors and exceptions in Azure Logic Apps Microsoft document for more information.
I am facing below error in respose,
<faultcode xmlns:ns1="http://xml.apache.org/axis/">ns1:Client.NoSOAPAction</faultcode>
<faultstring>no SOAPAction header!</faultstring>
i am trying to fixing in pipeline ,
selected pass all headers through pipeline but didn’t helpedenter image description here
Do you really need a SoapAction?
One of the options available in a proxy is to decide which operation a SOAP message is, by inspecting the message body.
If someone sends a message (perhaps through a biz ref) and doesn't include a SOAP action header, a proxy will still recover if it uses this method.
My application returns the error code 40003 when a I try to signin indicating that user already exists, but this is desirable for my application. So, I do not want to see my listener failing in red. Is it possible to write something that converts the listener response to green even if response code is an error.
Add Response Assertion as a child of the HTTP Request sampler and check Ignore Status box.
You can also add an extra check to ensure that response code is 40003like
See How to Use JMeter Assertions in Three Easy Steps guide for more information on conditionally setting requests and responses status using Assertions.
I'm new to the .NET web api. But I can't figure out what the best practice should be when returning status codes. I've followed the tutorial on creating a web api that supports crud operations to get a good idea on how it all works.
I have a spec where the response to every request returns a status code along with other data, I can change the spec if need be but I can't work out if it's good to return a status code and also return all the data requested or to just return the data on it's own.
For example if I made a request to GetAllCarManufacturers without being authenticated I'd return a custom statusCode of 1 (Indicating not authenticated), and message "User is not authenticated.". But if I was authenticated I'd like to send back a statusCode of 0 (indicating success) and all the car manufacturers. This seems to go against the way the tutorial is organised as only the car manufacturers are sent back without any additional data. Which leads me to believe passing around a statusCode isn't the correct thing to do.
I've seen in the example crud demo that HttpResponseExceptions are thrown which sets the HttpStatusCode to a certain value (see code below). Should I be using that instead of returning my own status code? But then my concern is it doesn't have enough different status codes that will match my custom scenarios.
// Setting the HTTPStatusCode example.
throw new HttpResponseException(HttpStatusCode.NotFound);
.NET Web API sets up a convention for HTTP calls to a server that supports a REST interface. So, if you follow the convention, you should return HTTP Status Codes as a way of indicating what happened to the request when the server processed it.
HTTP Status Codes are part of the HTTP spec and can be found here.
There are many benefits to using HTTP Status Codes. One is that the HTTP Status Code is a header, so the client doesn't have to look into the content of the response in order to find out what happened.
So, returning a custom status code (of say 0 or 1) is not very useful to HTTP clients if they expect a RESTful experience from your interface.
When constructing an API response, which method is better for (manually) returning the status code to indicate the validity of the request:
1 - Embed a response code within the JSON response
{
'status_code' => 200,
'status_message' => 'OK',
'data' => { ... }
}
2 - Or is it better to modify the HTTP Headers Status field?
Request URL:http://somesite.com
Request Method:GET
Status Code: 200 (EDITING THIS ONE)
I would think that the HTTP Statuses should only be regarding connection errors and file retrieval errors that occur at the server level rather than altering this to address application level errors.
Any good articles and resources to read would be very appreciated as well.
I have found the best way to present errors in a REST Request is to change the HTTP Status Code to the proper error, and embed the error in the response.
If you are using JSON, it might look like this, with the status code set to 500 for this example:
{"error" : "An error has occurred while trying to read from the database."}
This is the same method that Microsoft CRM uses to report errors, and it has proved to be a good method; RESTFul applications will not fail to parse the response if they are expecting JSON (or XML, if you are using that).
This question addresses the same issue (perhaps from a slightly different perspective).
I think that, in general, if a request to a resource in your application results in an error condition, that fact should be reflected in the HTTP headers. You can use the application response to provide more detailed information.
Update: Here is an interesting mapping of application errors to status codes (used by Azure).