How do you communicate an error to the web service consumer ?
For example, my web service has a function to insert employee into db.Suppose while inserting the data , the database gave an error,what should be the best way to inform the user about the error.
One way is to depict it through the return value of the web service method but what to do when the function is supposed to return a complex object like employee when there is no error ,and will send an error string when there is an error ?
For SOAP: That is what faults are used for
SOAP faults are used to carry error information within a SOAP message. The fault is for SOAP what an exception is for a programming language.
When your client's request succeeds, you send back a valid response with the Employee structure, when it fails, you send back a fault with details of what went wrong.
For REST: Use HTTP Error Codes
Unlike SOAP, REST web services do not have a convention for returning errors but the simplest is to use the ones everybody understands.
For example you might send a HTTP 404 Not Found when a record is missing, a HTTP 500 Server Error when something happend on the database etc, and return HTTP 200 OK with your result when everything is fine and dandy.
Related
I was doing a automation testing on my web application with SOAPUI, I have found a bug which is http method fuzzing basically it means "HTTP Method Fuzzing
An HTTP Method Fuzzing Scan attempts to use other HTTP verbs (methods) than those defined in an API. For instance, if you have defined GET and POST, it will send requests using the DELETE and PUT verbs, expecting an appropriate HTTP error response and reporting alerts if it doesn't receive it.
Sometimes, unexpected HTTP verbs can overwrite data on a server or get data that shouldn't be revealed to clients."
Can anyone knows how I can solve this issue or how I block the HTTP request other than GET or POST which may remove this bug.
I am using Node.js and express for my web application.
Please check the images:
Image 1
Image 2
I am currently using a wcf odata web service with entity framework. My code returns an internal server error (500) while performing post operation from edmx file. But the data gets posted because I am performing insert/update operation using queries later in code.
I want to force return a success status code 200 and skip this "500 status code (internal server error). An error occurred while processing this request" since my functionality works well.
How can I achieve this? Any suggestion?
I've a two-way WCF receive port, where i've checked both:
1) Route failed messages
2) Suspend request message on failure
This configuration is needed to redirect failed messages to our "exception portal".
When a message is received and it fails validation in XMLReceive pipeline, the message is redirected to our "exception portal" as expected.
The problem is however that the consumer of the WCF service never get's a fault, so the Connection gets a timeout after a while, which is very confusing for the consumer.
Is there anyway to fix this problem? Am I missing something?
What's happening currently is that the message fails on the Receive pipeline, gets routed to your portal, but no response gets routed back. You have to make sure to send a message back. You could do that by:
creating an Orchestration that does the validation (instead of doing it on the pipeline), and making sure to send a response int he orchestration as well as routing failures to your portal
creating a custom component that validates the message (perhaps by calling the XML Validation pipeline in a try block and catching the exception without rethrowing it); on error it sends the message to your portal, and replaces pInMsg with something sensible to send back to the partner.
having your portal receive location be a request response port (perhaps, again, with an orchestration behind it), and route the response back to the WCF two way port. This way is more involved, and to be honest I'm not entirely sure what a working implementation would look like here, but it may be possible.
If it were up to me, I'd go for the Orchestration. You can certainly call the XML Validator pipeline from an orchestration, or you could use other validation logic in there (for example calling BRE).
I am using webMethods from the SAG and it seems if the service
pub.client.http
throws an exception on status code 401 "Unauthorized".
This leads me to the problem that I cannot handle the status code because nothing is written to the pipeline.
getLastError
does contain the string "Unauthorized" but not the status code.
Except that I do not want to start parsing exception messages...
Any ideas?
The output parameter header from the pub.client.http call should contain the information you’re after:
header Document Conditional. HTTP response headers.
Key Description
lines Document Fields in the response header, where key names represent
field names and values represent field values.
status String HTTP status code of the response.
statusMessage String HTTP status message of the response.
See the webMethods Integration Server Built-In Services Reference page 122 for more details.
Asked a SAG senior consultant.
This is the normal behavior.
There is no flag which you can set to enforce suppression of this exception...
You can suppress the exception and have the HTTP 401 status returned like any other HTTP response. Go to the IS Admin Extended Settings and set:
watt.net.http401.throwException=false
Note this is a server-wide setting, so it will affect all your applications/services that use pub.client:http.
According the comment from #Hugo Ferreira probably there are ACL restriction whether inside your webMethods environment, or your client URLs.
Things you should consider:
Do your webMethods server located inside closed environment wherein need to get connected to proxy to get to the outgoing request. Which is likely you can investigate by run web-browser program directly from your wM server towards the URL address (i.e using SSH to run firefox in my case and popup appeared)
The client that your request will go to, have HTTP for authentication requests
Solution
To pass this all you need to do is input the auth user/password or any other auth mechanism i.e kerberos, token, etc. inside the pub.client:http
We have a REST service deployed in production, which returns an XML serialised representation of a simple object.
When calling the REST 'get' method, we see a very strange problem, whereby after all our user code is finished (according to our own logs), we get a 401 in the browser which is rendering the object XML. It's failing server-side during the execution of the 'return' statement in the REST method.
We think we understand this part of the problem... The object contains an enum, whose value is actually returned from a database. In this particular case we have managed to assign an integer value to the enum which isn't defined in the Enumeration itself (This behaviour is permitted, and is the reason for Enum.IsDefined method: http://msdn.microsoft.com/en-us/library/system.enum.isdefined.aspx)
Our assumption is that when the REST framework code processes the 'return' statement, it then tries to serialise the Enum to a text value, and blows up because no name (string) exists for the specified value.
Strangely though, rather than getting a yellow screen of death or similar, we get a 401 (and a prompt for credentials in the browser).
We were wondering if ASP.NET / IIS does some sort of Server.Transfer in these cases, but perhaps it doesn't have filesystem permissions to the page it is transferring to - ? We're baffled as to what is going on under the bonnet! There is no client-side redirect.
Any ideas anyone?
An HTTP status code of 401 means Unauthorized. From wikipedia:
401 Unauthorized
Similar to 403 Forbidden, but specifically for use when authentication is possible but has failed or not yet been provided.[2] The response must include a WWW-Authenticate header field containing a challenge applicable to the requested resource. See Basic access authentication and Digest access authentication.
I would start looking at how your authentication is set up.