I understand that you can describe your REST webservice while using WSDL.
Is this a good idea if you don't use WCF? Is there a better way to allow service discovery and bind your request/response to certain types?
If you use json you can use SMD and JSON-Schema but what if you use XML or YAML?
EDIT:
I have found this specification for WADL.
How widely used is it?
The Http Accept header and Content Type headers are there to allow a client to dynamically request and respond to different types. Statically describing what those types are in some kind of description file like WSDL would be unnecessarily limiting.
The use of hyperlinks within the returned representations allows for incremental service discovery. This allows the service discovery to be dynamic based on a whole range of factors.
The use of a global static service discovery document like WSDL or WADL is really not the optimum solution with a REST service.
Related
Is it mandated by any standard that a web service should provide a WSDL by appending ?wsdl to the endpoint address?
Is it OK if the WSDL is hosted at a different URL (without appending ?wsdl)?
For example:
Endpoint: http://abc.xyz.com/MyService
WSDL: http://abc.xyz.com/MyServiceDefinition.pqr
Note that I'm even using a different extension for the WSDL definition.
Does using this approach violate any standards or one can host the thing the way they want?
Is it mandatory to have a WSDL definition accessible using ?wsdl?
No, it's not.
A WSDL is used to describe a web service contract and is provided because it allows tools to automate generation of client stub code for calling the specified web service. Exposing the WSDL at the same location as the web service with ?wsdl appended to it is just very handy and that's the convention everybody uses.
People and tools look for the WSDL at that location and frameworks automatically expose it at that location but it's just a convention. As to my knowledge this isn't specified in any specification (or at least none that I could find).
Sometimes though you don't want to provide a WSDL that everybody can look at and try to create a client because it's a private web service and you only want to give access to your partners, not to everybody. At that point you can disallow the ?wsdl URL and provide the WSDL only to your partners by using an alternative channel. You can even e-mail it if you don't want it exposed online.
So you can choose whatever channel to expose it. Just remember that because people and tools are following this convention they are used to see it there and some (poorly written) tools might choke in a different extension, for example.
P.S. One other thing I wanted to mention - which isn't strictly related to this answer but kinda reinforces the convention - is the new ?singleWsdl option in WCF 4.5.
WCF, as most other tools, exposes the WSDL at the ?wsdl address but uses xsd:import statements with external schemas. Some frameworks were not able to process WSDL with imported dependencies so people started to write customizations over WCF to have a flat WSDL exposed, so much so that in the latest version of WCF Microsoft decided to add this feature out of the box.
But for backward compatibility they needed to keep the ?wsdl endpoint as it was (returning a WSDL document with xsd:import statements inside) and were forced to add a new query parameter for the flat WSDL: ?singleWsdl. I'm sure this idea will be picked up by other web service vendors and providers as well.
No, Its not mandatory to have ?wsdl access, but its recommended way.
Its worth noting that most clients will try to append "?wsdl" to your URL and will try to access WSDL file, Hence its highly recommended to setup it.
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.
Am new to web services. I have a spring bean in which i have used Transactional annotation for DB operations.
Now I need to expose one of the method in the bean as a service.
The method parameters are Hashmap and a POJO (like JPA entity) object. return type is HashMap.
What is the best way to implement it.
Directly exposing the bean using Axis2.
Using Spring-Ws with CXF.
Writing a new method in a new wrapper class which accepts Strings as parameters.
(These string are actually as required by the original Map and POJO ).
And by setting these strings as properties and objects in POJO and Map respectively, as required by original method.
The Third method wont work in my case as the Map will contains several arraylists which needs to be stored in DB.So I have to use Map only.
Shall I go with SOAP or RESt.
Already two web services were provided using Axis2 in our project by old team.
We are using spring 3 (as core container and for ORM), Hibernate template, Tomcat 6.
Well, that question is best answered by yourself. We can only give hints here which framework and technology might work out best for you. In order to give any hint, we'd need some more information about your project.
SOAP and REST, for example, are two essentially different technologies. The SOAP protocol must use XML as information medium and can use literally any transport medium, e.g. HTTP, E-Mail, JMS, etc. Using SOAP, the contract, which is the WSDL specification, between a service endpoint and a client is the interface description. The REST protocol can use any information medium, e.g. JSON, XML, YAML, etc., but is limited to the HTTP protocol as transport medium. Here, the HTTP methods like DELETE, GET, POST are the interface description.
You said, you're actually using AXIS2. If your experiences with that framework are good enough, I would recommend to use it further. CXF is simply another Web Service Framework which cannot be used together with Spring-WS (but it can be used with the Spring Framework). Here, I would consider that each framework has its caveats and needs some time to learn.
I published an orchestration in Biztalk as a webservice. Does anyone know how I can use XML serialization or something to load XML from a file and "convert" it to the messagetype the webservice expects? How do people usually use this webservices? I try to avoid using untyped messages since I use both XML and flatfile, and have read that it could mean trouble.
Well, I guess generally the idea of web services is that you add a web reference to them, which would generate a set of proxy classes you could use to interact with the web service.
You don't normally have to worry about serialising xml files to and from the web service formats, the generated code will do it for you.
If you do wish to, however, to work of XML, you could use .net serialisation to deserialise an xml file into the generated proxy type (as well as serialise any response you're getting).
Here's a basic example of how to deserialise xml into a class instance, you can then pass this instance into the method in the generated proxy.
System.Xml.Serialization.XmlSerializer xser = new System.Xml.Serialization.XmlSerializer(typeof(<generated request type here>));
xser.UnknownAttribute += new System.Xml.Serialization.XmlAttributeEventHandler(xser_UnknownAttribute);
xser.UnknownElement += new System.Xml.Serialization.XmlElementEventHandler(xser_UnknownElement);
xser.UnknownNode += new System.Xml.Serialization.XmlNodeEventHandler(xser_UnknownNode);
xser.UnreferencedObject += new System.Xml.Serialization.UnreferencedObjectEventHandler(xser_UnreferencedObject);
<generated request type here> request = (<generated request type here>)xser.Deserialize(<xml stream here>);
I hope that makes sense
You question is bit confusing. You started off with saying you published an orchestration as web service, but raised the question about consuming it.
If you are talking about published web service:
The web service generated by BizTalk Web service Wizard is not different from a web service you would have written in .NET. Based on the message type you orchestration is expecting and how your structured the operation in the wizard. The Wizard would have auto generated a webservice for you with WSDL and schemas (there will be some BizTalk specific bits inside, but you don't need to worry about the implementation).
You consumers (independant of platform) should be able to consume that web service without any major issues.
If you are trying to consume a web service from Orchestration
Have a look at this paper http://msdn.microsoft.com/en-us/library/ms935219(BTS.10).aspx
I have build plenty of SOAP webservices, but am building a REST webservice for a specific project, and I was wondering what people used for a 'WSDL' for REST services or if it is even needed.
You can try Swagger(now OpenAPI) which allows to describe REST services using a JSON open standard.
REST really only uses the HTTP verbs (GET,PUT,POST,DELETE) on a resource. All operations on a resource are supposed to be represented that way. POST is used as a catch all for when you can't express your business logic in a way that fits into the other three. That is why there isn't really a WSDL for a REST service since you only ever have 4 methods on the resource. Note that the Zend Framework REST library isn't really RESTful and is more of a plain old XML (POX) service.
While Sam's correct that RESTful web applications don't need a direct analog to WSDL, there is an XML vocabulary that's useful for describing RESTful web apps: WADL, or Web Application Description Language. At my company we primarily use WADL to define a spec for a given service that we want to build - we don't generally use it programmatically. That said, the WADL home page includes some Java tools for code generation, and Restlet, the Java REST framework, includes a WADL extension for dynamically wiring applications based on WADL and dynamically generating WADL based on a wired application. I'm a fan of WADL, and recommend that you check it out.
Actually it's possible to use WSDL for that but it should be v 2.0 - see "Describe REST Web services with WSDL 2.0" article.
You can supply an XSD if you are using XML in your REST service.
Or just examples of the XML, should be enough to work things out for simple data structures anyway.