we are having SOAP and REST equivalent services exposed. I want to write a test cases in a way that I write it once and can check it for both SOAP and REST.
because each time there is more of some repetitive code for SOAP and REST and want to make consumer independent of it and focus more on its business details.
Can some one put there inputs on it. Or is something similar available?
Related
Is SOAP over HTTP a subset of XML over HTTP since I assume SOAP also an xml that confirms to a schema (SOAP schema)? I assume XML over HTTP service can either be accessed using GET or POST method. Does SOAP over HTTP always use POST method? In case of XML over HTTP I assume the disadvantage is that schema file has to be shared with all the consumers whereas in case of SOAP over HTTP it will be a single WSDL file. Would it be possible to help in letting me know the difference and also advantage of one over the other?
SOAP is a specialization of XML, as it has a schema, such as http://www.xmlsoap.org/soap/envelope/, whereas XML is more general.
For using GET, you can read through this discussion: http://www.coderanch.com/t/463869/Web-Services/java/SOAP-request-HTTP, but basically SOAP is done via POST, though Axis2 appears to have support for GET, as a way to have SOAP work in a world where REST seems to rule.
And, according to this IBM article (http://www.ibm.com/developerworks/xml/library/x-tipgetr/index.html) SOAP 1.2 introduces GET.
As you mentioned, SOAP is a standard, so there are tools that can easily work with it, including dynamic client generation, as shown in this question, dynamic proxy soap web service client in java?, whansere the client generates the stubs needed upon connection.
If you use XML over http, it may be better, depending on the need, as a way to transfer data, but in the use cases I can think of it would seem better to just use JSON and REST, but, if you want to transfer XML, or send XML, then you could look at using REST.
POST would be the better option though as GET has size limitations (maximum length of HTTP GET request?), which is probably why SOAP is almost always POST.
The WSDL is not necessarily a single file, in WCF, if I remember, there are many xml files that need to be put together for the WSDL to be complete.
The advantage depends on what your use case is, but I find that use REST and allowing the user to select the type is useful as it can be trivial to switch between JSON and XML, for example, and is the better choice for XML over HTTP.
SOAP is best when integrating with older technologies as that may be all they can easily use. For example, when I have made webservices for SAP integration, it can be more work to have it not use SOAP, depending on the ability of the ABAP programmer.
You may find this question of use:
How SOAP and REST work with XML/JSON response?
and for a discussion about JSON and XML in webservices you may find this helpful:
http://digitalbazaar.com/2010/11/22/json-vs-xml/
I forgot this link, as they do a brief comparison, but in the end you can easily support both. In WCF I had a controller that had the business logic, and had to .aspx files, one for SOAP and one for REST, and some webservices supported both, as it was just a matter of handling the request and response differences. So, if you want to provide support for both, and have a business case showing it makes sense, then pick a framework that will make it easy to do.
http://digitalbazaar.com/2010/11/22/json-vs-xml/
Basically, the goal is to provide services to clients via the web. What clients are going to connect? How will the clients find it easiest to reach out? How much data is being passed in the request?
These types of questions will lead to the best solution for your needs.
This question already has answers here:
Representational state transfer (REST) and Simple Object Access Protocol (SOAP)
(14 answers)
Closed 9 years ago.
I currently figure out the similar is both using internet protocol (HTTP) to exchange data between consumer and provider.
The difference is:
SOAP is a XML-based message protocol, while REST is an architectural style
SOAP uses WSDL for communication between consumer and provider, whereas REST just uses XML or JSON to send and receive data
SOAP invokes services by calling RPC method, REST just simply calls services via URL path
SOAP doesn't return human readable result, whilst REST result is readable with is just plain XML or JSON
SOAP is not just over HTTP, it also uses other protocols such as SMTP, FTP, etc, REST is over only HTTP
That's everything I know as the differences between them. Could anyone correct me and add more.
SOAP uses WSDL for communication btw consumer and provider, whereas
REST just uses XML or JSON to send and receive data
WSDL defines contract between client and service and is static by its nature. In case of REST contract is somewhat complicated and is defined by HTTP, URI, Media Formats and Application Specific Coordination Protocol. It's highly dynamic unlike WSDL.
SOAP doesn't return human readable result, whilst REST result is readable with is just plain XML or JSON
This is not true. Plain XML or JSON are not RESTful at all. None of them define any controls(i.e. links and link relations, method information, encoding information etc...) which is against REST as far as messages must be self contained and coordinate interaction between agent/client and service.
With links + semantic link relations clients should be able to determine what is next interaction step and follow these links and continue communication with service.
It is not necessary that messages be human readable, it's possible to use cryptic format and build perfectly valid REST applications. It doesn't matter whether message is human readable or not.
Thus, plain XML(application/xml) or JSON(application/json) are not sufficient formats for building REST applications. It's always reasonable to use subset of these generic media types which have strong semantic meaning and offer enough control information(links etc...) to coordinate interactions between client and server.
For more details regarding control information I highly recommend to
read this: http://www.amundsen.com/hypermedia/hfactor/
Web Linking: https://www.rfc-editor.org/rfc/rfc5988
Registered link relations:
http://www.iana.org/assignments/link-relations/link-relations.xml
REST is over only HTTP
Not true, HTTP is most widely used and when we talk about REST web services we just assume HTTP. HTTP defines interface with it's methods(GET, POST, PUT, DELETE, PATCH etc) and various headers which can be used uniformly for interacting with resources. This uniformity can be achieved with other protocols as well.
P.S.
Very simple, yet very interesting explanation of REST: http://www.looah.com/source/view/2284
In day to day, practical programming terms, the biggest difference is in the fact that with SOAP you are working with static and strongly defined data exchange formats where as with REST and JSON data exchange formatting is very loose by comparison. For example with SOAP you can validate that exchanged data matches an XSD schema. The XSD therefore serves as a 'contract' on how the client and the server are to understand how the data being exchanged must be structured.
JSON data is typically not passed around according to a strongly defined format (unless you're using a framework that supports it .. e.g. http://msdn.microsoft.com/en-us/library/jj870778.aspx or implementing json-schema).
In-fact, some (many/most) would argue that the "dynamic" secret sauce of JSON goes against the philosophy/culture of constraining it by data contracts (Should JSON RESTful web services use data contract)
People used to working in dynamic loosely typed languages tend to feel more comfortable with the looseness of JSON while developers from strongly typed languages prefer XML.
http://www.mnot.net/blog/2012/04/13/json_or_xml_just_decide
SOAP brings it’s own protocol and focuses on exposing pieces of application logic (not data) as services. SOAP exposes operations. SOAP is focused on accessing named operations, each implement some business logic through different interfaces.
Though SOAP is commonly referred to as “web services” this is a misnomer. SOAP has very little if anything to do with the Web. REST provides true “Web services” based on URIs and HTTP.
By way of illustration here are few calls and their appropriate home with commentary.
getUser(User);
This is a rest operation as you are accessing a resource (data).
switchCategory(User, OldCategory, NewCategory)
REST permits many different data formats where as SOAP only permits XML. While this may seem like it adds complexity to REST because you need to handle multiple formats, in my experience it has actually been quite beneficial. JSON usually is a better fit for data and parses much faster. REST allows better support for browser clients due to it’s support for JSON.
I'm starting in the web-services world and I have a few questions:
From what I've read, REST could be understood as a simple call to a URL which gives a certain expected result. So, what is the difference between a REST web-service and a simple website?
Web-services are language-independent. So, if I'm developing a Java-based REST web-service with a method that returns a serialized Person class object, and my client is a .NET application, how can this class be reconstructed on the .NET side? How is it done in practice? Do I have to build a representation of the returned object on the web-service and on the .NET side parse it and build it?
In practice, whats is the difference between REST and SOAP calls?
See the Richardson Maturity Model for an explanation on what a RESTful service is.
To reach level 3 one must satisfy the Hypermedia as the Engine of Application State. abrivated HATEOAS constraint (also called the Hypermedia constraint). This means that most services out there is not RESTful, but merly CRUD services... which is fine...
A good resource on REST is REST in Practice
The main difference between SOAP and REST is that REST services does not have a WSDL defining the "operations", thank god for that. Yet the data structures can be defined by a schema language such as Schematron, XSD for XML...
REST stands for Representative State Transfer. It is built on the fact that the HTTP protocol is stateless, and specifies some methods like PUT/GET/POST etc. REST attaches semantics to those methods. For example, a GET means 'Read/Load'. PUT means 'save'. POST means 'update'. (I think I got that right...)
So REST is not a call to a URL, REST is a concept. You use REST by making calls to Urls. The difference between REST and a 'simple website' is the REST semantics. A PUT request means one thing, a GET request means another, etc.
RESTful webservices are language independent because the depend on the HTTP protocol; thats it. They don't depend on any language features, other than the ability to use the HTTP protocol.
REST returns structured XML or JSON data, you don't send back an entire webpage, which could be hard to interpret, and would be unnecessarily complicated.
You can parse XML or JSON data into an object in any language with a parser for this (including the .net languages). An object in this sense doesn't mean a full fledged .net object with a vtable etc.
SOAP overloads the POST data sent with an HTTP request, and hence instead of having many URLs to which you send individual requests, you just have one URL to which you post some XML data. In reality, the difference is mostly semantic.
I see APIs such as PayPal, etc. offering to call their services using NVP or SOAP/WSDL. When using a .NET environment (3.5) using traditional web services (no WCF) which is better and why? I know WSDL lets you drop in the API URL and it generates the wrappers for you. So then why do companies even offer NVP?
There seems to be never-ending confusion in this industry about the different types of web services.
SOAP is a messaging protocol. It has as much in common with REST as an apple has with a lawn tractor. Some of the things you want in a messaging protocol are:
Headers and other non-content "attributes."
Addressing - routing of a message to different servers/recipients based on the headers;
Guaranteed delivery via queuing and other methods;
Encryption, signing, and other security features;
Transactions and orchestrations;
Accurate representation of complex structured data in a single message;
...and so on. This is not an exhaustive list. What WSDL adds to SOAP, primarily, is:
Discoverability via a contract, a form of machine-readable "documentation" that tells consumers exactly what is required in order to send a message and allows proxies to be auto-generated;
Strict, automated schema validation of messages, the same way XSD works for XML.
REST is not a messaging protocol. REST is a system of resources and actions. It is a solid choice for many architectures for several important reasons as outlined by other answers. It also has little to no relevance to "NVP" services like PayPal and flickr.
PayPal's NVP API is not REST. It is an alternative, RPC-like messaging protocol over HTTP POST for clients that don't support or have difficulty supporting SOAP. This isn't my opinion, it's a statement of fact. One of the fields in the NVP is actually METHOD. This is clearly RPC verbiage. Take a look at their API for UpdateRecurringPaymentsProfile and try to tell me that this makes a lick of sense to describe as a "resource". It's not a resource, it's an operation.
In the case of PayPal specifically, the "NVP" (HTTP POST) API is inferior to the SOAP API in almost every way. It is there for consumers who can't use SOAP. If you can use it, you definitely should.
And I'm not necessarily bashing PayPal for this, either. I know a lot of folks have bashed them for not putting together a "proper" RESTful API but that is not what I am getting at. Not every service in the world can be accurately described with REST. PayPal isn't really a resource-based system, it's a transactional system, so I can forgive their architects and developers for not having a perfectly elegant REST architecture. It's debatable perhaps, but it's not black-and-white. It's fine; I'll just use the SOAP system if I need to.
Compare this to, say, the Twitter API. This is a true REST service. Every "operation" you can perform on this API is accurately described as either the retrieval or submission of a particular kind of resource. A resource is a tweet, a status, a user. In this case it literally makes no sense to use a complex SOAP API because you're not really sending messages, you're not performing transactions, you're just asking for specific things, and these things can be described with a single URL. The only difference is that instead of getting an HTML web page back, you're getting some XML or JSON data; the way you request it is exactly the same.
A REST Web Service usually (always?) uses HTTP GET for the retrieval of some resource. And Twitter does exactly this. GET still uses "Name-Value Pairs" - that's the query string, ?q=twitterapi&show_user=true. Those bits after the ? are name-value pairs. And here's a great example of why you would want to use REST over SOAP; you can hook this up to an RSS feed and get streaming updates. I can turn it into a Live Bookmark in Firefox. Or I can download it in JSON format and bind it to something like a jqGrid. The interesting thing is not that the request uses "Name-Value Pairs"; the interesting thing is that it's a simple URL and can be consumed by anything that knows how to request a web page.
So to try and summarize all of what I've said, think of it this way:
Use a REST API (if available) when you want to expose data, or consume or publish it, as a permanent resource.
Use a SOAP API when the system is transactional in nature and/or when you need the advanced features that a complex messaging protocol can offer, such as RM and addressing.
Use an RPC API (which includes just about any API that's modeled entirely around HTTP POST) when there is no SOAP API or when you are unable to use the SOAP API.
Hope that clears up some of the confusion.
I assume that by Name Value Pairs, you mean REST services.
The benefits to REST are primarily ease of development, simplicity and elegance, and lower overhead (which is very important if you are sending and receiving a lot of small messages).
Here are some of the advantages of REST:
REST is more lightweight
Human readable results
Everything is a URI addressable resource
REST services are more easily cached
REST is easier to build (no toolkits are required)
REST is easier to call (HTTP - GET, POST, PUT, DELETE)
NVP is HTTP POST
name=fred
amount=100
code=403
etc
This is the default format from any HTML browser so it's simple to implement for sending data to a web service
I don't think it's a good format for receiving data from web service? JSON or XML would be more suitable
No everyone uses VisualStudio, or has access to automatic wrapper generators, or wants to use such a beast
Many web mashups are coded in Javascript, so using HTTP POST to send data is the simplest way. The return result is a standard HTML response code (200, 403, 500, etc) and/or some JSON
Many service providers offer multiple API's to cater for all customers
I am writing an interface for our VXML application that will allow access to a SOAP service.
Because of the difficulties inherent in trying to use javascript to make SOAP calls and the limitations of VXML, as in making external resource calls are pretty much limited to HTTP requests, GET and POST.
I designed a java servlet that would act as a service provider to the VXML application. It can call this servlet with arguments indicating the web service type, the method name to invoke and the arguments to pass to it. The servlet then makes the appropriate web service call and returns the response in a standardized VXML document response.
The issue is I severely underestimated how difficult SOAP really is. I thought I could just simply construct the soap call and do it in java, however its looking to me like this is something a little more involved, requiring things like Apache Axis2.
I read somewhere that listeners for Axis could be HTTP servlets, which sounds a lot like what I am doing already.
Am I re-inventing the wheel here?
Is there any suggestion out there for me as to how to do this better?
I am pretty invested in the way I'm doing it now and so would be very receptive to an easy way to accomplish the SOAP call and process the response from a jsp servlet.
EDIT - After taking the advice here I've delved a little further into Axis.
As it turns out, Axis2 is Apache's third generation of Apache SOAP. Whats unfortunate about this is that after extensive searching I cannot find a single solitary place where the original Apache SOAP implementation can be downloaded.
I might not care if:
A) Axis would allow me to integrate a few jars and jsps rolled
into a standalone WAR app
B) everything .. i mean everything up to this point has been done using
examples from ApacheSOAP (the book i was using, the code I've
written thus far .. everything).
So I google some more thinking .. hey, there has to be some kind of stand alone library for Java that would just simply allow me to make a single solitary simple SOAP call and parse the results.
But no, no such luck!
Apparently if you want to use Java and SOAP you have either the gigantic incomprehensibly thick and complicated axis or .. you roll your own soap implementation from the ground up. I am so burned on this. I don't get why soap is so wonderful given the last 7 13 hour days I've spent just trying to get a simple hello world request to work from JSP.
A library like Axis is definitely the solution, you do not want to attempt to build/parse SOAP messages on your own.
Look at using wsdl2java (another link, and another) to create client proxies for which you can invoke the web services. This will generate a bunch of Java code which you can call into from your code, and then Axis will handle packaging your arguments into XML messages, sending it across the wire to the server, de-serializing the response, etc.