×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Book Review: RESTful Java Web Services

samzenpus posted about 3 years ago | from the read-all-about-it dept.

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

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.

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

49 comments

REST is not an architecture (4, Informative)

Pieroxy (222434) | about 3 years ago | (#35883890)

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:REST is not an architecture (0)

Anonymous Coward | about 3 years ago | (#35883926)

Is there a book around that's good to recommend to the packt publishing people so that they will give it a REST?

Re:REST is not an architecture (0)

Anonymous Coward | about 3 years ago | (#35883966)

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?

Re:REST is not an architecture (0)

Anonymous Coward | about 3 years ago | (#35884136)

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.

Re:REST is not an architecture (1)

luis_a_espinal (1810296) | about 3 years ago | (#35885318)

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 (4, Informative)

ebcdic (39948) | about 3 years ago | (#35884270)

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:REST is not an architecture (1)

Covener (32114) | about 3 years ago | (#35884362)

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:REST is not an architecture (0)

Anonymous Coward | about 3 years ago | (#35884282)

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

Re:REST is not an architecture (1)

vlm (69642) | about 3 years ago | (#35884636)

... 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:REST is not an architecture (1)

IntentionalStance (1197099) | about 3 years ago | (#35888686)

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.

Re:REST is not an architecture (0)

Anonymous Coward | about 3 years ago | (#35885250)

REST is a meaningless buzzword. All it means is "a different url will return a different thing."

Re:REST is not an architecture (1)

luis_a_espinal (1810296) | about 3 years ago | (#35885350)

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:REST is not an architecture (1)

toriver (11308) | about 3 years ago | (#35885798)

Well, clearly you need to read up on the subject since you don't know Jack about it.

Re:REST is not an architecture (1)

Ryyuajnin (862754) | about 3 years ago | (#35887414)

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.

Re:REST is not an architecture (0)

Anonymous Coward | about 3 years ago | (#35888854)

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

Re:REST is not an architecture (1)

DiegoBravo (324012) | about 3 years ago | (#35892464)

The time it takes to read the first 1% of those great WS-* specs is enough to build a full featured rest-styled system.

Re:REST is not an architecture (0)

Anonymous Coward | about 3 years ago | (#35898950)

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 (0)

Anonymous Coward | about 3 years ago | (#35883932)

I found this book very relaxing.

Another Packt "Classic" (4, Funny)

McNally (105243) | about 3 years ago | (#35883994)

I tried clicking on the "Disable Advertising" checkbox but it didn't make this story go away..

Re:Another Packt "Classic" (0)

Anonymous Coward | about 3 years ago | (#35884104)

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.

Re:Another Packt "Classic" (0)

Anonymous Coward | about 3 years ago | (#35884376)

Counterpoint: Just because you're paranoid doesn't mean they're not out to get you.

Re:Another Packt "Classic" (1)

Anonymous Coward | about 3 years ago | (#35885154)

Counter-counterpoint: Just because they're out to get you, doesn't mean anyone wants to hear you whine about it.

Re:Another Packt "Classic" (1)

Anonymous Coward | about 3 years ago | (#35885202)

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:Another Packt "Classic" (0)

Anonymous Coward | about 3 years ago | (#35884460)

Seriously... another Packt review /. ??

Re:Another Packt "Classic" (0)

Anonymous Coward | about 3 years ago | (#35884790)

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.

Re:Another Packt "Classic" (1)

Tablizer (95088) | about 3 years ago | (#35887430)

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!"
   

What about Drupal? (1)

Anonymous Coward | about 3 years ago | (#35884050)

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... (0)

Anonymous Coward | about 3 years ago | (#35884070)

... it were RESTful Erlang web services

Re:Would be cooler if... (2, Informative)

Anonymous Coward | about 3 years ago | (#35884480)

CouchDB provides an Erlang RESTful JSON API [apache.org] that can be accessed from any environment that allows HTTP requests.

Re:Would be cooler if... (1)

Curien (267780) | about 3 years ago | (#35891622)

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.

I am sure (1)

codepunk (167897) | about 3 years ago | (#35884084)

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

Re:I am sure (1)

Lord_Naikon (1837226) | about 3 years ago | (#35884230)

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.

Re:I am sure (0)

Anonymous Coward | about 3 years ago | (#35884390)

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.

Re:I am sure (1)

M. Baranczak (726671) | about 3 years ago | (#35885040)

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 (1)

arjan_t (1655161) | about 3 years ago | (#35885434)

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.

crook review; as thermal thursday approaches (-1)

Anonymous Coward | about 3 years ago | (#35884112)

no crime? no charge? no spine. see you at the mormormonic temple down under in southern hillary.

disarm

How the actual book defines REST (0)

Anonymous Coward | about 3 years ago | (#35884874)

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

What are the chances... (1)

Haedrian (1676506) | about 3 years ago | (#35885210)

Just spent half a day looking for REST stuff and this pops up.

Its almost like I'm being tracked. *tinfoil hat*

I have a book review too... (0)

Anonymous Coward | about 3 years ago | (#35890108)

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 (1)

Lennie (16154) | about 3 years ago | (#35891230)

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.

Any better than usual (dreadful) Packt book? (0)

Anonymous Coward | about 3 years ago | (#35894168)

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.

Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...