Java SOA Cookbook

Chapter 8. RESTful Web Services

Introduction

SOAP is a specification. WSDL is a specification. XML Schema is a specification. Although developers and architects may hotly debate exactly how implementations of SOAP-based web services should be written or how they should be used, there is no question about what these things are. They are concrete, and exist. Like a cup.

SOA, and even ESB, on the other hand, are more conceptual in nature. Their principles are clear, but they really represent architectural styles and strategies. They are therefore more open to interpretation than the likes of SOAP and WSDL; their very definitions are open to considerable debate. So while people can generally agree on the key principles of SOA (loose coupling, etc.) and on key features of an ESB (routing, mediation, transformation, etc.), the devil is always in the details.

SOA, ESB, and REST have no specifications. As a result, vendors may take whatever 15-year-old EAI software they have lying around and re-brand it as their “SOA Stack” now that SOA has become the chief topic of conversation at every dinner table in the country. (Or at least in every software-company lunchroom.) And as with SOA and ESB, there are many contributing factors to the sense that REST is in the middle of a lot of contention out there. Java developers who may be used to having clearly defined APIs have to make a slight shift when it comes to thinking about SOA, ESB, and REST. Sun can’t simply tell us exactly what they are—we have ...