|
|
Featured White Papers
- Why choose an Open Source BPM?
- 10 FAQs on Business Process Management
- Best Practices for Getting Started with BPM
- Free Your Devs From The Pain Of Java Redeploys
- Increase Velocity 40% by Using JRebel
- What Developers Want: The End of Application Redeploys
- Developer Productivity Report: Java Tools, Tech, Devs, and Data
- Coding with JRebel: Java Forever Changed
- Utilizing Fast Testing to Transform Java Development
- Do You Really Get Classloaders?
- Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
- Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
- Coding with JRebel, Java Forever Changed
- 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data
Sponsored Links
Sponsored Links
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
REST for Java developers, Part 1: It's about the information, stupid
A resource-oriented approach to Web services
Page 4 of 4
Representation
The final portion of this architectural style is the R in REST: representation. This is the structural form of the resource as it moves back and forth from client to server. In Java and other object-oriented languages, we think about objects, but by giving resources logical names, you do not have a strict binding between an information consumer and producer and can therefore negotiate the form when you ask for it. This is one of the key advantages of REST over SOAP as far as information management is concerned. You do not want the same physical structure or level of detail back in all situations. XML may be a great format in the business tier, but JavaScript frameworks tend to have difficulty with this data-interchange lingua franca. In a browser-based API, you might like to refer to the same resource but ask for it back as JavaScript Object Notation (JSON). There is no reason, if the server can support the request, for the client to get back anything other than what it needs. With this flexibility in place, however, you can build frameworks that automatically serialize the returned value into Java, C#, or other objects you can use. It is like having the simplicity of Java remote method invocation (RMI) without its Java-only limitations.
In conclusion
As an architectural style, REST is simple and flexible, and it allows the various communicating pieces to change over time. This flexibility gives you the resilience to embrace the change that inevitably comes in the form of new use cases, new technologies, new requirements, or a new understanding of your domains. Software achieves scalability by talking to logical names that might map to a load balancer that redirects to multiple back-end responders. Clients do not need to know which specific machine they are communicating with. To meet the needs of this kind of an environment, you need an integration approach that separates out the concerns of:
- The things we care about
- How we refer to them
- How we manipulate them
- How we choose to represent them for creation, updates, and retrieval
The simple diagram in Figure 3 shows how REST implements this separation of concerns:
Figure 3. Separation of concerns
WSDL-based SOAP systems do not give you this flexibility. They bind you to a contract that controls what is being asked and of whom, and what will be returned. It is difficult to change any part of that without affecting the clients using the service. REST isn't immune to this problem, but more opportunities to route around it are available. Document/Literal style SOAP has more flexibility than the remote procedure call (RPC) approach, but you lose the ability to name the request and the results the way you can in REST via URLs. This makes it much harder to identify cacheable requests. It is not impossible, and work is being done to improve the situation, but the collection of specifications needed to manage relatively simple requests starts to feel like overengineering.
When you need to invoke behavior in standard, contract-bound ways between disparate partners, SOAP is a good approach. If, on the other hand, you are looking to share information in flexible, scalable, reusable ways, then REST is a great approach. If you would like to build systems that do not require constant migration in the face of back-end flux, then REST's resource-oriented approach gives you that flexibility. The trick is to focus on the information. Who wants it? How do they want it? What do they know and what do they need to know? If you can build software systems that efficiently satisfy these needs, you will add tremendous business value to your customers and give yourself a long-term architectural strategy for success.
In the next article in this series, you'll explore Restlet, an API that makes it easier to build and consume RESTful services in Java.
About the author
Brian Sletten is President of Bosatsu Consulting, Inc. a services company focused on using Web and semantic-oriented technologies to solve architectural and data-integration problems not handled by conventional tools and techniques. He has a background as a system architect, developer, mentor, and trainer, with experience in the defense, finance, and commercial domains. Brian has a B.S. in computer science from the College of William and Mary and lives in Fairfax, VA.Read more about Enterprise Java in JavaWorld's Enterprise Java section.
- Feedback
More from JavaWorld
Resources
- In a talk with Andy Glover, "Brian Sletten on REST done right" (JavaWorld, June 2008), Brian demystifies REST as an application protocol, not a transport protocol, and describes the series of interactions that define REST.
- XFire creator and Mule Galaxy chief architect Dan Diephouse shares his views on REST vs. SOAP, and explains his migration from Web services development toward a RESTful approach to SOA (JavaWorld, July 2008).
- "REST easy with the JavaBeans Activation Framework" (Jeff Hanson, JavaWorld, October 2007) is a hands-on introduction to the JAF as a vehicle for RESTful data transmission.
- Read "Architectural Styles and the Design of Network-based Software Architectures" (Roy Fielding, University of California, Irvine, 2000), the doctoral dissertation that defined REST.
- "Latency is zero" is one of the Fallacies of Distributed Computing credited to Sun's Peter Deutsch.
- The Restwiki is dedicated to explaining and advancing the REST architectural style.
- Read more about URI opacity and REST.
- The family of SOAP specifications is maintained by the World Wide Web Consortium.
- Albert Einstein's "On the Method of Theoretical Physics" lecture, source of the "supreme goal of all theory" quote, was delivered at Oxford in 1933.
More
- Visit JavaWorld's Web services & SOAs research center to learn more about technologies for developing Web services.
- JavaWorld's community platform is growing: Check out JW Blogs and the new Java Q&A Forums.
- Also see Network World's IT Buyer's Guides: Side-by-side comparison of hundreds of products in over 70 categories.