I was thinking into digging a little dipper into the REST type of web services and noticed that there aren't any specifications for it as opposed to SOAP web services.
Why is that?
Each language uses its own standards.
According to Wikipedia:
Unlike SOAP-based web services, there is no "official" standard for RESTful web services. This is because REST is an architecture, unlike SOAP, which is a protocol.
http://www.w3.org/Protocols/rfc2616/rfc2616.html - Http Uniform interface specification
http://tools.ietf.org/wg/httpbis/ - Latest revisions to HTTP spec
https://datatracker.ietf.org/doc/html/draft-gregorio-uritemplate-04 - URI Templates
https://datatracker.ietf.org/doc/html/draft-nottingham-http-link-header-06 - Link Headers and link relations
http://www.iana.org/assignments/media-types/ - Loads of links to specs for media types
These should be all the specs you need to get going to build a RESTful system over HTTP.
Are there specific WS-* specifications that you feel you are missing to be able to build as REST based system?
Well, at least for Java there is JAX-RS http://en.wikipedia.org/wiki/JAX-RS, but i don't know if this is based on some other standards.
OData (http://docs.oasis-open.org/odata/odata/v4.0/odata-v4.0-part1-protocol.html) is a standard for RESTful WebServices and should fit your needs (at least if you're using any MS framework).
Btw. if you want do use a standard and make the WebService as open and reusable as possible, WADL (http://www.w3.org/Submission/wadl/#x3-40001.3) the WSDL equivalent for REST could help.
Related
Two questions
Two questions on JAX-WS and JAX-RPC
Besides annotations, how do I distinguish JAX-WS from JAX-RPC?
What simple POCs can I do to appreciate JAX-WS is better to use than JAX-RPC? (besides the reason that JAX-RPC is the older version). I have read all about JAX-WS and it's advantages but I find it card to figure out thinking of concrete examples or simple proof of concept that would prove that its better use it than JAX-RPC.
Can anyone help?
Your first question is covered by this one. To summarize, there are descriptor files present for JAX-RPC, since it uses XML mapping documents to describe reflection-based rules for marshal/unmarshal.
As for your second question, I suggest writing the same HelloService web service (provider) using both frameworks. I think you'll find JAX-WS much easier, if for no other reason than finding tutorial documentation. Use two web modules and follow tutorials to create the same functionality.
Take a look at the artifacts for both. Also experiment with adding complex Java types as input or output. Notice that JAX-RPC cannot automatically convert many WSDL/schema constructs to a Java equivalent - a great side by side comparison article (and series) is here.
A personal anecdote - due to the JAXB underpinnings, the JAX-WS service will be much more forgiving if the request message has small deviations from the WSDL such as unexpected input elements, etc. Why is this important? Versioning & maintenance. With JAX-RPC, it was much more difficult to update the service provider with new fields without breaking JAX-RPC client applications, and vice versa.
Spec Time
I've seen it mentioned that JAX-RPC is deprecated as of JavaEE 6. I don't see that wording specifically (it is listed for server implementors as "proposed optional"; the PDF spec says the following:
EE.12.2.3
JAX-WS JAX-WS, along with JAXB and the Metadata for Web
Services specification, provides simpler and more complete support for
web services than is available using the JAX-RPC technology.
Applications that provide web services using JAX-RPC should consider
migrating to the JAX-WS API.
(emphasis mine).
The JavaEE 7 spec lists JAX-RPC not only as optional (for server implementors); it also includes it in the list of "pruned Java technologies" - candidates for outright removal in subsequent JavaEE spec versions.
All this to say: you don't earn your way out of the JavaEE specification if you're the better spec.
I am working on a Java EE project where there is a need to incorporate Web Services to transmit and receive data to/from external sources. I am not sure which way to go, Axis2 or JAX-WS.
Any suggestions will be appreciated.
The choice of a web services stack depends on what standards you actually need. Here are some stacks currently available:
The JAX-WS reference implementation is part of Java and provides basic support, including WS-Addressing, but not WS-ReliableMessaging or WS-Security. The big advantage is that you do not get additional dependencies by using the RI.
Another option is Axis2, which also provides support for these standards. As far as I know, the use of Axis2 is declining and personally, I found it rather hard to use (That's basically an opinion, I do not want to start a flame war).
I would suggest to consider a third option: CXF. It is another implementation of a web service stack and supports roughly the same as Axis2. I found it rather easy to set up and use and personally prefer it to Axis2.
One more option is Metro. Metro bundles the JAX-WS reference implementation and the Web Services Interoperability Technologies (WSIT). WSIT provides an implementation for several more standards and is tuned to provide interoperability with WCF.
Here is an article that compares these stacks with a little more detail. My suggestion would be: If you only need basic stuff (no reliable messaging, security, etc.) use the reference implementation. If you need support for additional standards, go for CXF or Metro.
Metro is the way to go! At lest for me :)
please see my comment in a similar question.
It depends on your requirement. What type of implementation you require.Java from its 1.6 version provides API for JAX-WS type of web service creation. But, really it's just for the basic requirement. If you want ws-Security,ws-policy etc. then please go for Axis2. Actually in Axis2 they have made lot of improvement from it's Axis 1.x version. The new STAX implementation is one of them. Apart from that Axis2 has made service creation part lot easier. Even, they support RESTful web services also.
I am looking for resources to show me how I can consume web services inside native C++ . Are there any popular libraries I can use?
TIA
Andrew
It really depends on what webservice architecture you are talking about... For XML-RPC IBM has a nice article showcasing XMLRPC++, for SOAP there is e.g. gSOAP or WSO2 WSF/C++, ...
There are the Axis2/C libraries, which, while C based rather than C++, are still easily employable - when I was working on Apache Tuscany, we used Axis2/C for our C++ Web Service bindings.
From the Axis2/C front page:
"Apache Axis2/C supports SOAP 1.1 and SOAP 1.2, as well as REST style of Webservices. A single service could be exposed both as a SOAP style as well as a REST style service simultaneously. It also has built in MTOM support, that can be used to exchange binary data."
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.
My gut feel is that document based web services are preferred in practice - is this other peoples experience? Are they easier to support? (I noted that SharePoint uses Any for the "document type" in its WSDL interface, I guess that makes it Document based).
Also - are people offering both WSDL and Rest type services now for the same functionality? WSDL is popular for code generation, but for front ends like PHP and Rails they seem to prefer rest.
Document versus RPC is only a question if you are using SOAP Web Services which require a service description (WSDL). RESTful web services do not not use WSDL because the service can't be described by it, and the feeling is that REST is simpler and easier to understand. Some people have proposed WADL as a way to describe REST services.
Languages like Python, Ruby and PHP make it easier to work with REST. the WSDL is used to generate C# code (a web service proxy) that can be easily called from a static language. This happens when you add a Service Reference or Web Reference in Visual Studio.
Whether you provide SOAP or REST services depends on your user population. Whether the services are to be used over the internet or just inside your organization affects your choice. SOAP may have some features (WS-* standards) that work well for B2B or internal use, but suck for an internet service.
Document/literal versus RPC for SOAP services are described on this IBM DevelopWorks article. Document/literal is generally considered the best to use in terms of interoperability (Java to .NET etc). As to whether it is easier to support, that depends on your circumstances. My personal view is that people tend to make this stuff more complicated than it needs to be, and REST's simpler approach is superior.
As mentioned it is better to choose the Document Literal over RPC encoded whenever possible.
It is true that the old java libraries (Axis1, Glue and other prehistoric stuff) support only RPC encoded, however in today's most modern Java SOAP libs just does not support it (e.x. AXIS2, XFire, CXF).
Therefore try to expose RPC encoded service only if you know that you need to deal with a consumer that can not do better. But then again maybe just XML RPC could help for these legacy implementations.
BiranLy's answer is excellent. I would just like to add that document-vs-RPC can come down to implementation issues as well. We have found Microsoft to be Document-preferring, while our Java-based libraries were RPC-based. Whatever you choose, make sure you know what other potential clients will assume as well.