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.
Related
When I'm tasked with dealing with connecting to web services, I've always found the appropriate .wsdl file, ran WSDL2Java.bat, and incorporated those Java files into my Java project. Then I've successfully completed my project that needs to access data via web services.
My question is, are there other ways to use the .wsdl file to access web services? ( I'm not talking about creating classes for different languages ). For example, I have documentation describing one company's web services. The examples it shows in it's documentation are essentially dumps of HTTP Post requests. Is this "web services"? It looks to me that the .wsdl file is merely used as a reference to make the correct Post requests. I could just make text templates and plug in the right values, and send them out, right? I really feel like I'm missing something here.
Am I a web-services illiterati?
To call a SOAP web service over HTTP you just need to send it a properly formatted XML with a POST request. That's it! How you build the request is irrelevant as long as it conforms to the SOAP protocol and the payload corresponds to a proper web service operation that exists on the particular web service you are calling.
But how do you know how to build the proper payload?
The web service needs to have some sort of documentation otherwise you don't know what to put inside the XML. The documentation can be whatever you like as long as people can use it to build valid requests. WSDL fits this criteria but has an extra advantage: you can feed it to a tool that generates code. That code knows how to handle all the SOAP details and exposes objects and methods to your application.
What would you prefer? Generating code from the WSDL in a few minutes and be able to call whatever operation on the web service or, build the requests and parse the responses by hand and spend hours or days doing so. What would your boss or company prefer? :)
It looks to me that the .wsdl file is merely used as a reference to make the correct Post requests. I could just make text templates and plug in the right values, and send them out, right?
Right! But you also have to consider your productivity as an employee in one case as opposed to the other.
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.
What would be the preferred method of pulling content from a remote database?
I don't think that I would want to pull directly from the database for a number of reasons.
(Such as easily being able to change where it is fetching the info from and a current lack of access from outside the server.)
I've been thinking of using HTTP as a proxy to the database basically just using some PHP to display raw text from the database and then grabbing the page and dumping it to a string for displaying.
I'm not exactly sure how I would go about doing that though. (Sockets?)
Right now I am building it around a blog/news type system. Though the content would expand in the future.
I've got a similar problem at the moment, and the approach I'm taking is to communicate from the client app with a database via a SOAP web service.
The beauty of this approach is that on the client side the networking involved consists of a standard HTTP request. Most platforms these days include an API to perform basic HTTP client functions. You'll then also need an XML or JSON parser to parse the returned SOAP data, but they're also readily available.
As a concrete example, a little about my particular project: It's an iPhone app communicating with an Oracle database. I use a web service to read data from the database and send the data to the app formatted in XML using SOAP. The app can use Apple's NSURLConnection API to perform the necessary HTTP request. The XML is then parsed using the NSXMLParser API.
While the above are pretty iPhone-specific (and are Objective-C based) I think the general message still applies - there's tools out there that will do most of the work for you. I can't think of an example of an HTTP API offhand, but for the XML parsing part of the equation there's Xerces, TinyXML, Expat...
HTH!
You might look at using AJAX (I recommend JSON instead of XML though). This is the technology underlying Google Maps.
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