One of the difference which I read is "Unlike WCF Rest we can use full features of HTTP in Web API"
WebApi and wcf rest both uses Http only but I am not sure what do we mean by full features of Http here.
What are the Http features which are available in webApi but not in wcf rest.
Could somebody explain please.
I think WebAPI is better than WCF because of some points of HTTP features:
Support many formats: JSON, XML, Text, binary, ...
Can customize Header and Body
Easy to custom URL
Simpler and faster (WCF is SOAP-based service)
Support many HTTP Status codes
Support multiple devices because the simple response and easy to customize for small devices like phone
Related
I have recently implemented a CORS IDispatchMessageInspector applied through a BehaviorExtensionElement for services within a large project I am working on to allow for CORS support (arising from calling REST WCF web services from jQuery Ajax calls).
The current implementation intercepts all OPTIONS method calls to an endpoint with the CORS behavior specified and responds with the appropriate headers (and a 200). As it stands the service will expect to see OPTIONS requests only in the case of CORS requests, however I cannot guarantee that this will always be the case.
In the interests of future proofing and extensibility, what are the most common reasons for OPTIONS requests outside of CORS? Are there plans to extend the use of such requests in future WC3 specs (as this seems to suggest)? Are there any use cases that I should attempt to allow for?
It's the other way around.
A CORS preflight request will be an OPTIONS request including an Origin and Access-Control-Request-Method request header, by which you can recognize it as such.
Any other OPTIONS request is just that, and can be sent by any client for any reason.
WebDAV clients are known to use OPTIONS to probe for support for protocol levels and method support (see RFC 4918).
How to test web services which is written in PHP as "HTTP Raw Request" , I tried J meter Raw request Plugins, but i donno what to give in Request Data, And Data File Path ????
Kindly Suggest me to go further in Jmeter !!!!
SOAP Web Services are talking XML. REST Web Services are accept and reply JSON.
For XML-based Web Service you should be using
SOAP/XML-RPC Request to send a request itself
XPath Extractor - for correlation (extract dynamic values from response for re-using)
XPath Assertion - for checking that response is expected
For REST-based Web Service following components are quite good:
HTTP Request - to send requests
HTTP Header Manager - to hold Content-Type and any other headers
JSONPath Extractor (available via plugin) - for correlation
JSONPath Assertion - for testing
Perhaps Testing SOAP/REST Web Services Using JMeter guide can be a good place to start with.
Has SOAP exclusively used HTTP POST historically? In other words, does SOAP mainly use HTTP POST for all types of request? In comparison, the RESTful approach may be to use request types closely matching the purpose of the message. I wondered what the current and historical stance has been for SOAP.
SOAP mainly considers the use of HTTP POST historically (though can use other protocols such as SMTP) for request and response since version 1.1. However, since version 1.2 it can use GET requests with no SOAP message receiving a SOAP response. (Papazoglou, Michael P. (2008). Web Services: Principles and Technology. Harlow: Pearson Education Limited. p140-143.)
I have an ASP.NET web service running that accepts both HTTP POST and SOAP requests. Are there any disadvantages to using a simple HTTP POST to get the data from the WS instead of using SOAP over HTTP?
I can't think of anything else other than the support for transmission of complex data types, and I don't think I'll need that in this project.
Thanks,
Teja.
The clue is in the question...
using a simple HTTP POST to get the data
A POST is not a GET, a GET is a GET.
If you're the only person operating on the WS then it's not a problem as long as you are handling your incoming connections properly. If it is open to outsiders then I would recommend sticking to conventions, they are there to save us from ourselves :)
I have to use a 3rd party web service implemented in .NET 2.0 (on IIS, of course).
I have to make a java client. I am using wsdl2java to generate the SOAP stub.
As the original Apache Axis project now appears unmaintained, and I was having some problems parsing some responses from the service, I converted the client to use the latest (1.5) version of Axis2. Now, the .NET service won't even recognize my requests.
I managed to get the "chunking" turned off (where "stub" is a variable of type MumbleStub generated by wsdl2java, and I am showing what are several lines of code as one horrific line here):
stub._getServiceClient().getOptions().setProperty( HTTPConstants.CHUNKED, Boolean.FALSE);
.. so at least the service recognizes my request AS a request, albeit a bad one: "HTTP/1.1 400 Bad Request" is the response now (as opposed to an "intro / summary" page offering me a link to the WSDL).
I noticed that the Axis ("1") request had a different Content-TYpe header (text/xml, vs application/soap-xml), and I am wondering how to change this request header, if that is in fact the problem.
Alternately, has anybody else had this problem? Is the problem really the (undisplayable here, as it looks like "element injection" to the blog engine) ... xml version-"1.0" ... "XML meta intro tag" that Axis2 added to the beginning of the request?
WS-Deathstar, indeed.
As you mention the different content-type header I guess your client tries to send SOAP 1.2 requests and the 3rd party app only understands SOAP 1.1
Try changing the used soap version as AFAIK AXIS2 uses SOAP 1.2 by default
stub._getServiceClient().getOptions().setSoapVersionURI(org.apache.axiom.soap.SOAP11Constants.SOAP_ENVELOPE_NAMESPACE_URI);