The first problem I encountered is that the wadl2java documentation describes very good how to use the generator but doesn't speak of using the generated code. Thus while the generation went smoothly, using the generated code meant reading the generated source code to figure out what each function does and how to use it. And I thought that generating a client would make my life simpeler!
As I see this blog as a way to share stuff I learned so that hopefully someone who needs the same information can google this up, I'll try to explain who I think it has to be used. A single class EndPoint is generated containing a lot of inner classes. Using the inner classes, you can build the URL you would like to access.
/resource becomes new EndPoint.Resource()
/resource/contract becomes new EndPoint.Resource.Contract()
/resource/{id} becomes new EndPoint.Resource.Id(id)
/resource/{id}/contract becomes EndPoint.Resource.IdContract(id)
The inner classes have methods combining the HTTP method and representation. Some examples should clarify this.
getAsHtml() does a HTTP GET to retrieve a HTML representation
getAsJson() does a HTTP GET to retrieve a JSON representation
put() performs a HTTP PUT with as input a DataSource
What you get back (or need to send in case of a PUT/POST) is of type DataSource. Some things you can do with this DataSource object:
- Retrieve a representation out of it:
dataSource.getInputStream()
- Put an XML representation in it:
String updatedPerson = "
";
input = new ByteArrayDataSource(updatedPerson.getBytes(), "application/xml");
I like the wadl2java generation as fast client builder but I think it has a lot of shortcomings to provide a powerful interface to a REST service. It should also make it easier to use more advanced features as caching, conditional GET, error handling and such. I know understand the concerns of others that when using WADL you dumb down REST and hide the advanced features. It has the same problems as giving WSDL client generation to the developer masses so that they aren't aware of how powerful SOAP and WS-* can be.
Posts
6 reacties:
The generated EndPoint class should also have a getAsWhateverMyBoundClassIs() method. This won't actually get generated unless everything is just so in your wadl2java invocation and there are no errors.
Two other gotchas to look out for in the 1.0 and 1.1 releases:
1) you cannot nest your resources inside of another resource that has path "/", and
2) all your document elements must have a namespace.
Hello,
Do you know how to make authenticated call (using for example HTTP basic authentication) using the generated wadl2java generated code?
Cheers.
I'm afraid doing the authenticated call falls under the "advanced" rest features. If I remember well, you can't add an authentication header or any HTTP header for that matter.
Hi,
Thanks for sharing!
I have used wadl2java 1.1 to generate POJOs from a wadl file describing the PlaceFinder Geocode service http://developer.yahoo.com/geo/placefinder/
However, after hours and hours of googling and trying I have not been successful using the generated code. This blog, alongside a chapter in the book "Java Web Services: Up and Running, 1st Edition" are the only sources discussing the use of the generated code.
The generated code does NOT give me a method called getAsWhateverMyBoundClassIs() (as Dave put it). It only gives me GeoCode.getAsTextXml(). I have not succeeded in casting the response to any of the generated POJOs. And I dont see any XML when I issue the statement System.out.println(response.getInputStream().toString());
* What should I do to get the method getAsWhateverMyBoundClassIs()?
* If that is not possible, what should I do to cast the getAsTextXml() to a POJO?
* Why are there no online samples on using the wadl2java output?
Cheers.
I have the impression that the wadl2java is no longer developed since nothing changed since I checked it out in may 2009 and nobody seems to be using it. In fact since its functionality is so limited and undocumented, I think it is better to use for example jersey and write the code yourself.
Thanks for your input!
I am sad to hear the suggestion though since I saw wadl2java as a great initiative. I like the idea of well-described interfaces and abstraction of binding and transport.
However, I guess you are right. What would you recommend me to choose?
Transport:
- apache wink?
- any jersey restful client?
- some more basic http?
- something else?
Binding:
- xpath?
- xmlbeans?
- jaxb?
- something else?
I have tried different combinations, but have had a hard time making it work.
As I said I have been able to generate wadl and xsd files using soapUI for the service I would like to invoke.
Would you have any recommendation/sample for how to succeed with the RESTful client implementation?
Post a Comment