In an answer to another question it was mentioned that passing XML as a string parameter to a web service was bad practice. What is the reason for this?
This question is at least in part due to a comment of mine about string parameters containing XML being bad practice in web service design. Here's why:
If the web service author wanted his service to accept XML, with or without a schema, then he should have defined the parameter as being of the XML Schema type <xs:any/>. That permits an arbitrary XML element. It's possible to restrict the permitted XML by using <xs:any namespace="xml namespace" processContents="strict" />. This will restrict the XML to being from the particular namespace, and will validate the XML against schemas. The recipient of such a message will be able to process it as pure XML, or possibly as type object or XmlElement or the platform equivalent.
In contrast, if XML is passed as a string, then the recipient has to take action to turn it back into XML. This assumes that actual XML has been properly encoded into the string.
Passing a string also loses you the benefits of XML. For example, the encoded XML cannot be easily processed by XML-based tools, such as XSLT.
I have used many web services that take simple XML values as a parameter or return them as output, so I am not sure exactly why someone would consider it to be a bad practice, but I could describe a few of the weaknesses.
The main downside that I can see to using arbitrary XML as an input parameter is that by itself it does not provide strong typing. If you are using a SOAP based web services with a WSDL that outlines the web service input and output variables then using basic XML as a variable does not give the user very much information. This is especially the case if you have a basic string input value to which you assume the user will enter XML data. A better approach is to use an XMLElement or XMLNode type instead of a standard string, so that there is at least a basic level of type checking for valid XML in the web service. The idea with SOAP and WSDL though are to create strongly typed parameters so that full objects can be passed back and forth across the wire between applications. You basically can create an object and use that as the basis for your input or output values and SOAP will handle the creation of a schema for serialization and de-serialization for you automatically.
The problem is that using complex data types can significantly increase the complexity required for calling the web service. Web services are offered in a variety of flavors from simple REST services to a complex web of WS - * protocols for strongly typed messages. Using Plain Old XML with no schema would definitely be a bad idea if you are building a Business to Business web service based on WS - *, but if you are creating a simple REST service then POX might suit your needs just fine.
Its bad practice because it opens your web server to potential injection or XSS or URI poisoning types of attacks. Most web servers are never updated or patched even when they are identified as vulnerable to attacks.
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.
Is there is any possibility (special approach or wsdl2cfc utility) to generate web service (or it’s stub) with complex input output parameters and custom failure messages based on specified WSDL? I’ve read a lot of articles which describe how to consume that type of web services, but I haven’t found any article which describes how to implement them.
you can specify the WSDL a CFC presents with the wsdlfile attribute, so you can certainly present an existing WSDL, if that's what you've got. Getting CF to map things properly when the service is invoked is another matter. I would start by taking the WSDL you have, making a CFC use it and implementing the right method names with no specified arguments and CFDUMPing the arguments structure to see what CF is getting.
You can do quite a lot to present the web service you want by using CFCs with the right names and CFPROPERTY tags in them. You can also specify in a CFARGUMENT that the type="foo[]" and the generated WSDL will expect a list of FOO objects to be passed in.
I've no experience with returning custom errors through a web service, you may have to play with what CFTHROW does from within a web service
I assume you're trying to implement a service that already exists?
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.
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.
What is the difference between an XML Schema and WSDL?
The difference I noticed is that WSDL contains XSD and in WSDL we can declare operations, but not in XSD. Is that correct?
WSDL (Web Services Description Language) describes your service and its operations - what is the service called, which methods does it offer, what kind of in parameters and return values do these methods have?
It's a description of the behavior of the service - it's functionality.
XSD (Xml Schema Definition) describes the static structure of the complex data types being exchanged by those service methods. It describes the types, their fields, any restriction on those fields (like max length or a regex pattern) and so forth.
It's a description of datatypes and thus static properties of the service - it's about data.
XSD defines a schema which is a definition of how an XML document can be structured. You can use it to check that a given XML document is valid and follows the rules you've laid out in the schema.
WSDL is a XML document that describes a web service. It shows which operations are available and how data should be structured to send to those operations.
WSDL documents have an associated XSD that show what is valid to put in a WSDL document.
XSD : XML Schema Definition.
XML : eXtensible Markup Language.
WSDL : Web Service Definition Language.
I am not going to answer in technical terms. I am aiming this explanation at beginners.
It is not easy to communicate between two different applications that are developed using two different technologies. For example, a company in Chicago might develop a web application using Java and another company in New York might develop an application in C# and when these two companies decided to share information then XML comes into picture. It helps to store and transport data between two different applications that are developed using different technologies. Note: It is not limited to a programming language, please do research on the information transportation between two different apps.
XSD is a schema definition. By that what I mean is, it is telling users to develop their XML in such a schema. Please see below images, and please watch closely with "load-on-startup" element and its type which is integer. In the XSD image you can see it is meant to be integer value for the "load-on-startup" and hence when user created his/her XML they passed an int value to that particular element. As a reminder, XSD is a schema and style whereas XML is a form to communicate with another application or system. One has to see XSD and create XML in such a way or else it won't communicate with another application or system which has been developed with a different technology. A company in Chicago provides a XSD template for a company in Texas to write or generate their XML in the given XSD format. If the company in Texas failed to adhere with those rules or schema mentioned in XSD then it is impossible to expect correct information from the company in Chicago. There is so much to do after the above said story, which an amateur or newbie have to know while coding for some thing like I said above. If you really want to know what happens later then it is better to sit with senior software engineers who actually developed web services. Next comes WSDL, please follow the images and try to figure out where the WSDL will fit in.
***************========Below is partial XML image ==========***************
***************========Below is partial XSD image ==========***************
***************========Below is the partial WSDL image =======*************
I had to create a sample WSDL for a web service called Book. Note, it is an XSD but you have to call it WSDL (Web Service Definition Language) because it is very specific for Web Services. The above WSDL (or in other words XSD) is created for a class called Book.java and it has created a SOAP service. How the SOAP web service created it is a different topic. One has to write a Java class and before executing it create as a web service the user has to make sure Axis2 API is installed and Tomcat to host web service is in place.
As a servicer (the one who allows others (clients) to access information or data from their systems ) actually gives the client (the one who needs to use servicer information or data) complete access to data through a Web Service, because no company on the earth willing to expose their Database for outsiders. Like my company, decided to give some information about products via Web Services, hence we had to create XSD template and pass-on to few of our clients who wants to work with us. They have to write some code to make complete use of the given XSD and make Web Service calls to fetch data from servicer and convert data returned into their suitable requirement and then display or publish data or information about the product on their website. A simple example would be FLIGHT Ticket booking. An airline will let third parties to use flight data on their site for ticket sales. But again there is much more to it, it is just not letting third party flight ticket agent to sell tickets, there will be synchronize and security in place. If there is no sync then there is 100 % chances more than 1 customer might buy same flight ticket from various sources.
I am hoping experts will contribute to my answer. It is really hard for newbie or novice to understand XML, XSD and then to work on Web Services.
XSD is to validate the document, and contains metadata about the XML whereas WSDL is to describe the webservice location and operations.
XSD (XML schema definition) defines the element in an XML document. It can be used to verify if the elements in the xml document adheres to the description in which the content is to be placed.
While wsdl is specific type of XML document which describes the web service. WSDL itself adheres to a XSD.
WSDL - It contains the Operation such as Methods which a webservice provides.and these method can accept simple data types such as int,float etc and complex data types such as objects ,vectors, arrays etc. so mapping this to an xml datatype xsd are used. and based upon the xsd an user who wants to acccess webservice from different platform can provide the data appropriately.
Refer : ayazroomy-java.blogspot.com to read about basics of webservice.
If someone is looking for analogy , this answer might be helpful.
WSDL is like 'SHOW TABLE STATUS' command in mysql. It defines all the elements(request type, response type, format of URL to hit request,etc.,) which should be part of XML. By definition I mean:
1) Names of request or response
2) What should be treated as input , what should be treated as output.
XSD is like DESCRIBE command in mysql. It tells what all variables and their types, a request and response contains.
XSD is schema for WSDL file. XSD contain datatypes for WSDL. Element declared in XSD is valid to use in WSDL file.
We can Check WSDL against XSD to check out web service WSDL is valid or not.