Book Review: RESTful Java Web Services

← Back to Stories (view on slashdot.org)

Book Review: RESTful Java Web Services

Posted by samzenpus on Wednesday April 20, 2011 @06:36AM from the read-all-about-it dept.

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. 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. 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. .

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.

49 comments

Min score:

Reason:

Sort:

REST is not an architecture by Pieroxy · 2011-04-20 06:42 · Score: 4, 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

--
Write boring code, not shiny code!
1. Re:REST is not an architecture by Anonymous Coward · 2011-04-20 06:46 · Score: 0
  
  Is there a book around that's good to recommend to the packt publishing people so that they will give it a REST?
2. Re:REST is not an architecture by Anonymous Coward · 2011-04-20 06:48 · Score: 0
  
  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?
3. Re:REST is not an architecture by binarylarry · 2011-04-20 07:01 · Score: 2
  
  Chill our and relax bro, you're gonna have a heart attack.
  
  --
  Mod me down, my New Earth Global Warmingist friends!
4. Re:REST is not an architecture by Anonymous Coward · 2011-04-20 07:06 · Score: 0
  
  If you're examining the implementation details of common scenarios in common environments, yes (at least as far as amount of content, regardless of complexity), if you're just talking about the basic concepts, no, not really. The book seems to be focusing on the former so it's probably not a waste of space.
5. Re:REST is not an architecture by ebcdic · 2011-04-20 07:20 · Score: 4, 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
6. Re:REST is not an architecture by Anonymous Coward · 2011-04-20 07:21 · Score: 0
  
  That's funny. There are 17 references to architecture in that document included the first line...Representational State Transfer (REST) is a style of software architecture
7. Re:REST is not an architecture by Covener · 2011-04-20 07:28 · Score: 1
  
  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.
8. Re:REST is not an architecture by vlm · 2011-04-20 07:51 · Score: 1
  
  ... 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?
  
  --
  "Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
9. Re:REST is not an architecture by Anonymous Coward · 2011-04-20 08:54 · Score: 0
  
  REST is a meaningless buzzword. All it means is "a different url will return a different thing."
10. Re:REST is not an architecture by luis_a_espinal · 2011-04-20 09:03 · Score: 1
  
  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>
11. Re:REST is not an architecture by luis_a_espinal · 2011-04-20 09:06 · Score: 1
  
  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>
12. Re:REST is not an architecture by toriver · 2011-04-20 10:12 · Score: 1
  
  Well, clearly you need to read up on the subject since you don't know Jack about it.
13. Re:REST is not an architecture by Ryyuajnin · 2011-04-20 13:58 · Score: 0
  
  Thank you, Pieroxy, for nailing that on the head so well. I especially liked how you said GOOD practices, and not BEST; because the last REST implementation I recall working on (starts with "Al" and ends in "Fresco") was about as frustrating as using a sledge hammer to fix a pair of eye glasses. REST is SOMETIMES a good idea, but NEVER the soul architecture anyone would EVER want to base a host of applications on, nor is it even capable of being that; subsequently, this is why you have never heard anyone compare REST to a robust architecture such as: EJB, Spring, or Rails. Why (thanks again to Pieroxy)? Because REST is ONLY an idea with no official specification.
14. Re:REST is not an architecture by IntentionalStance · 2011-04-20 15:44 · Score: 1
  
  Read Fielding's Thesis - for me the most interesting part is where he discusses and suggests a definition of an architecture. If I recall, he defines an architecture as a set of design constraints chosen to achieve a set of goals.
15. Re:REST is not an architecture by Anonymous Coward · 2011-04-20 15:58 · Score: 0
  
  good practices?. REST is complete madness, the WS-* stack already have a lot of infraestructure ready for you and finally interoperable between vendors, in REST you should rewrite badly authentication, and other bits. There is no easy way to share your service description to your QA team and communicate the changes, the list goes and goes. What are those good practices again?.
16. Re:REST is not an architecture by DiegoBravo · 2011-04-21 01:07 · Score: 1
  
  The time it takes to read the first 1% of those great WS-* specs is enough to build a full featured rest-styled system.
17. Re:REST is not an architecture by Anonymous Coward · 2011-04-21 08:11 · Score: 0
  
  that is an hyperbole, you don't need to read all of them, or read them at all, just choose an appropriate tool or library for your language/platform choice, and dive deep only in the features you absolutely need. Current tools use heavy use of annotations for both REST and WS-* can''t see how you can be so much more productive with a REST approach.
RESTful Java Web Services by Anonymous Coward · 2011-04-20 06:46 · Score: 0

I found this book very relaxing.
Another Packt "Classic" by McNally · 2011-04-20 06:51 · Score: 4, Funny

I tried clicking on the "Disable Advertising" checkbox but it didn't make this story go away..
1. Re:Another Packt "Classic" by Anonymous Coward · 2011-04-20 07:01 · Score: 0
  
  You do realise that a high number of reviews is probably simply because Packt send out free review copies of their books to relevant people? Not everything is a conspiracy you know.
2. Re:Another Packt "Classic" by Anonymous Coward · 2011-04-20 07:29 · Score: 0
  
  Counterpoint: Just because you're paranoid doesn't mean they're not out to get you.
3. Re:Another Packt "Classic" by Anonymous Coward · 2011-04-20 07:34 · Score: 0
  
  Seriously... another Packt review /. ??
4. Re:Another Packt "Classic" by Anonymous Coward · 2011-04-20 08:07 · Score: 0
  
  In a better world no amount of advertising would help him.
  If the best thing you can think of for a title, is to slam an acronym on the cover, you're an abysmal writer.
5. Re:Another Packt "Classic" by Anonymous Coward · 2011-04-20 08:43 · Score: 1
  
  Counter-counterpoint: Just because they're out to get you, doesn't mean anyone wants to hear you whine about it.
6. Re:Another Packt "Classic" by Anonymous Coward · 2011-04-20 08:48 · 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?
7. Re:Another Packt "Classic" by Tablizer · 2011-04-20 14:00 · Score: 1
  
  I tried clicking on the "Disable Advertising" checkbox but it didn't make this story go away..
  I kept clicking it also, until it said, "Give it a REST already, Dude!"
  
  --
  Table-ized A.I.
What about Drupal? by Anonymous Coward · 2011-04-20 06:56 · Score: 1

How does Drupal fit into this? Seeing as this is a Slashdot Book Review.... surely there must be some Drupal angle?
Would be cooler if... by Anonymous Coward · 2011-04-20 06:58 · Score: 0

... it were RESTful Erlang web services
1. Re:Would be cooler if... by Anonymous Coward · 2011-04-20 07:36 · Score: 2, Informative
  
  CouchDB provides an Erlang RESTful JSON API that can be accessed from any environment that allows HTTP requests.
2. Re:Would be cooler if... by Curien · 2011-04-20 23:32 · 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 consumer should never, ever have to construct a URL in a semantically meaningful way (e.g., [databasename]/[tablename]/[rownumber]). That isn't to say the URLs can't be arranged that way, but in a RESTful environment, that bit of information would be completely irrelevant.
  
  --
  It's always a long day... 86400 doesn't fit into a short.
I am sure by codepunk · 2011-04-20 07:00 · Score: 1

Does it talk about the twenty or so xml config files I would have to edit just to get one running?

--

Got Code?
1. Re:I am sure by Lord_Naikon · 2011-04-20 07:15 · Score: 1
  
  I know you're trying to be funny but to enable Jersey for example you only have to add a couple of lines to web.xml. The actual REST interfaces are defined using annotations.
2. Re:I am sure by Anonymous Coward · 2011-04-20 07:30 · Score: 0
  
  Spring MVC another good framework that supports REST out of the box with minimal XML config. I had a RESTful application running in about 10 mins.
3. Re:I am sure by M.+Baranczak · 2011-04-20 08:30 · Score: 1
  
  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.
Re:Java Is DEAD by rbrausse · 2011-04-20 07:00 · Score: 1

you forgot to write something like "REST in peace", no idea why you missed this one
You don't need the book, just use this guy slides by Anonymous Coward · 2011-04-20 07:30 · Score: 1

You don't need the book, just use this guy slides
http://matthewturland.com/slides/jersey/
--posting anonymous so the poor sob do not know who I am !
Re:Java Is DEAD by JonySuede · 2011-04-20 07:31 · Score: 1

yeah like scala !

--
Jehovah be praised, Oracle was not selected
Packt Again? by mholve · 2011-04-20 08:12 · Score: 0

I for one welcome our new corporate overlords...
How the actual book defines REST by Anonymous Coward · 2011-04-20 08:15 · Score: 0

Here's a link to the Safari Books Online version of this book. The link shows the "What is REST?" portion of chapter 1.
http://bit.ly/ib3Oee
All books on web services are RESTful... by frank_adrian314159 · 2011-04-20 08:20 · Score: 1

All books on web services are RESTful... I tend to fall asleep about five pages in.

--
That is all.
What are the chances... by Haedrian · 2011-04-20 08:49 · Score: 1

Just spent half a day looking for REST stuff and this pops up.
Its almost like I'm being tracked. *tinfoil hat*
Java EE 6 - Zero XML by arjan_t · 2011-04-20 09:18 · 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.
Yawn by IanBevan · 2011-04-20 09:27 · Score: 1

Well surprise surprise, another Packt book. Please stop this advertising.

--
Never, ever lose a file again. Ever.
I have a book review too... by Anonymous Coward · 2011-04-20 18:46 · Score: 0

It is called "Giving Java a Rest"
Java has been around since 1995 and has, unlike the much younger PHP, gone nowhere.
"Compile once, run anywhere" is a solution for a problem nobody really cared or cares about.
Minecraft is the only Java program with widespread use.
Complicating things beyond any recognition by Lennie · 2011-04-20 22:20 · Score: 1

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, it is mostly the programmers, it is their style. It tends to be the same kind of programmer which had the same kind of education. For some reason you can't explain it to them either.

--
New things are always on the horizon
Any better than usual (dreadful) Packt book? by Anonymous Coward · 2011-04-21 03:13 · Score: 0

The reviewer writes:
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.
I've bought 3 Packt books, and they were universally DREADFUL: poorly written, poorly edited, and with HUGE technical gaps.
If this book is similar to most Packt books, then I'd run screaming.
If it's significantly better than the usual run of Packt books, the topic is interesting enough to maybe make me hold my nose and try one more time.
BTW, there's a manning book on Restlets out in MEAP form. It's got some blemishes too, but there's some good info on Restlet 2.0 in there. If anyone has seen that and this Packt book, I'd be very interested in a comparison.