Book Review: RESTful Java Web Services 49
jm2dev writes "The title is self descriptive, you will learn what a REST architecture is, the concepts behind it, advantages and constraints, and how to implement web services in a RESTful way serving and consuming content using the Java programming language, as command line applications, desktop graphical client, run by an application server or even as standalone applications. Almost everything you need to know to start working with web services in Java the REST way is covered by this book." Read on for the rest of Jose's review.
No previous knowledge about REST is required, as the author presents a good introduction to Representational State Transfer; although the reader is supposed to understand the Java language syntax as you can expect because of the title. Any further familiarities are not needed, because to use the code samples only the Java Development Kit is required, so you can try it and play with it on any computer with a java SDK, like OpenJDK 6, installed and configured, with your favorite plain text editor or with a fully featured modern IDE.
.
| RESTful Java Web Services | |
| author | Jose Sandoval |
| pages | 258 |
| publisher | Packt Publishing |
| rating | 9/10 |
| reviewer | Jose Miguel Martinez Carrasco |
| ISBN | 978-1-847196-46-0 |
| summary | Learn the concepts and ideas behind REST web services and implement working solutions using different popular frameworks. |
The book starts with an introduction to the REST software architectural style. The concepts behind REST, their main components, constraints and ideas that made a software system RESTful. The details of the HTTP requests and responses interchanged by clients and servers are explained. And the role that REST services play in Service Oriented Architectures is discussed.
Next, several clients to consume web services using the Twitter messaging API are explained and the simplicity to consume REST web services will encourage readers to experiment with other REST web services available in Internet.
The ability to retrieve information from more than one web service is a nice feature practically implemented as a simple mashup in the third chapter. A web page displays the results obtained by requests to Google, Yahoo, Twitter and TextWise's SemanticHacker REST web services.
Now that the way to consume information provided by REST web services has been explained, it's time to start thinking about the other part of the equation: considerations to design a REST web service are introduced, discussed, and a simple microblogging solution is developed and used during the next chapters. From my point of view this part is very useful, as the author has done a good job providing a reusable solution, and remarking how important is in modern software development to provide a smart design that can fit different scenarios with minimum modifications.
Readers will be able to implement a single desktop client, to perform those actions, and although this approach looks like has lost popularity among developers, this section will be useful for those developers that are in the need to create a desktop client instead of a web based one.
Clients need servers to consume information from, and the next chapters describe popular frameworks like Restlet (both versions 1.1 and 2.0), Sun's Jersey (now Oracle's) and JBoss' Resteasy, with a clear emphasis on their usage of JAX-RS implementation, and finally Struts 2 with the REST plugin. How the same REST web service can be implemented using any of them is a worthy reminder of the fact that properly modularized software provides a valuable way to reuse existing code. The author tries to be neutral but he highlighted important aspects to consider before choosing any of them like, as the features they provide can fit better different scenarios.
Although a client consuming web services have been implementing as a desktop client and as a web based client using servlets and JSP pages, the introduced frameworks provide a simpler way to implement clients, which is very handful because they are needed to test our web services work as we expect. Regarding this aspect, developed in chapter nine, I miss a chapter talking about REST web services testing that can be used in continuous integration environment to automate our tests.
Finally, additional topics are treated like authentication and security, which aren't essential to get the basic functionality, but are needed frequently in real world applications and here you will find a nice introduction to those topics.
I found this book very well structured, starting with an introduction to REST concepts and architecture, its advantages and constraints, and a comparison against other alternatives. Complexity is managed terrifically, as readers see their questions answered with working solutions, that can be easily tested in a computer with a working java development environment. Starting with how to query popular web services with a browser, and later on implementing our first and simple clients and servers with widely used open source frameworks.
From my point of view, Java developers with no experience in REST architectures will find this book specially useful, despite your experience the book provides a good explanation of well designed architectures and how important they are to achieve a working, elegant and easy to maintain solution, and this aspect is exposed with working and useful implementations.
Packt Publishing books are characterized by a well formatted text with easy to understand language and at the same time being precise. It is these facts that make even this technical book a pleasurable reading experience.
The code provided through out all the book are easy to understand and implement. Here the author made a good work explaining the key concepts and how they are translated into code. Furthermore, in order to be practical, the needed Java libraries are provided, almost eliminating the chance to incur in compilation errors. Of course, a working implementation can be downloaded for those of the reader who prefer not to type more than the essential.
Jose Miguel is a java software developer and open source enthusiast based in London. @jm2dev
You can purchase RESTful Java Web Services from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
REST is not an architecture (Score:5, Informative)
REST (in its original sense) is not an architecture, it's a bunch of concepts and good practices.
http://en.wikipedia.org/wiki/REST [wikipedia.org]
Re: (Score:2)
Chill our and relax bro, you're gonna have a heart attack.
Re: (Score:2)
I'm amazed that someone can take a concept as simple as REST and turn it into something so complicated it requires a book. A language-specific book, at that. Is writing a Java application that can examine an HTTP POST (GET|PUT|DELETE) really so complex it requires an entire book on the subject?
<sarcasm>The concept is so simple and yet Roy Fielding had to do a complete Ph.D. dissertation on it. A whole Ph.D. dissertation and now books. The fools!!!!
After all, as you said, REST is just HTTP POST (GET|PUT|DELETE), and nothing, but absolutely nothing else. Right, right? Dude you are so awesome! Teh l33t hax0r!11 </sarcasm>
Re:REST is not an architecture (Score:5, Informative)
Roy FIelding (who invented the term in his PhD thesis) described it as as "architectural style". See http://www.ics.uci.edu/~fielding/pubs/dissertation/abstract.htm
Re: (Score:2)
Everything in the story makes sense as describing an architectural style and some architectures that follow the principles of that style. Seems like the gotcha in the grandparent post is some mis-used can criticism of "is it written in REST?!". Extra lame points for trying to leave "architectural style" out to play up the difference.
Re: (Score:2)
... is not an architecture, it's a bunch of concepts and good practices ....
Whats an architecture style, if not a bunch of concepts and good practices?
Re: (Score:1)
Re: (Score:2)
REST is a meaningless buzzword. All it means is "a different url will return a different thing."
<sarcasm>
So, I could write a service that causes a change or side effect with each GET invocation (that is, a GET that is not idempotent) and I can still call it RESTful? Is that what you are saying in your infinite wisdom and professional experience?
After all, this will certainly fit the "a different url will return a different thing" description that you just proposed.
</sarcasm>
Re: (Score:2)
Well, clearly you need to read up on the subject since you don't know Jack about it.
Re: (Score:2)
The time it takes to read the first 1% of those great WS-* specs is enough to build a full featured rest-styled system.
Another Packt "Classic" (Score:5, Funny)
I tried clicking on the "Disable Advertising" checkbox but it didn't make this story go away..
Re: (Score:1)
Counter-counterpoint: Just because they're out to get you, doesn't mean anyone wants to hear you whine about it.
Re: (Score:1)
Yet the reviewers are either well-known Packt shills or actually people who take money and/or are employed by Packt. Also, the book is 2.5 years old now. Why would Packt choose to wait 2.5 years to give a reviewer a free copy?
Re: (Score:1)
I kept clicking it also, until it said, "Give it a REST already, Dude!"
Re: (Score:2)
you forgot to write something like "REST in peace", no idea why you missed this one
Re: (Score:2)
yeah like scala !
What about Drupal? (Score:1)
Re: (Score:2, Informative)
CouchDB provides an Erlang RESTful JSON API [apache.org] that can be accessed from any environment that allows HTTP requests.
Re: (Score:1)
That API does not appear to be RESTful. See all the places where they specify how to construct the query string to get various search results, or how to use which methods to perform various actions? Those are fundamental violation of REST.
The most fundamental aspect of REST is that a spider with no prior knowledge of the system could determine the syntax (not necessarily the high-level semantics, of course) for all operations simply by starting at a base URL and following all available links verbatim. The c
I am sure (Score:2)
Does it talk about the twenty or so xml config files I would have to edit just to get one running?
Re: (Score:1)
Re: (Score:2)
to enable Jersey for example you only have to add a couple of lines to web.xml
If it's deployed in Glassfish 3, you don't even need that.
Java EE 6 - Zero XML (Score:1)
In any fully compliant Java EE 6 application server(*), there is no configuration required at all. Just annotate a simple class in any package with @Path and @Produces. Then add a method that you annotate with @GET and you have a rest resource that can be invoked via the URL path specified in the annotations.
Zero XML and you literally have this running in under a minute.
*) Currently only Glassfish V3.x, but although not certified for the full Java EE 6 spec, JBoss AS 6 works too.
You don't need the book, just use this guy slides (Score:1)
You don't need the book, just use this guy slides
http://matthewturland.com/slides/jersey/ [matthewturland.com]
--posting anonymous so the poor sob do not know who I am !
All books on web services are RESTful... (Score:2)
All books on web services are RESTful... I tend to fall asleep about five pages in.
What are the chances... (Score:2)
Just spent half a day looking for REST stuff and this pops up.
Its almost like I'm being tracked. *tinfoil hat*
Yawn (Score:2)
Complicating things beyond any recognition (Score:2)
Why do Java programmers always want to complicate things beyond any recognition ?
Maybe we should just rename Java to CTBAR (like FUBAR) ?
With all their abstraction layers and after refactoring, they don't even know what the system is really doing.
I see this time and time again, the code is doing everything double, triple times or a 100 times, because it is hidden behind some kind of abstraction layer and they can't get to it or don't see what they are really doing.
Is isn't really Java that is at fault here,