Getting Started with RESTful Web Services Using JAX-RS
Web services have been out for awhile now. For some time, you could only create non-RESTful web services using the JAX-RPC specification. Working with web services early on became somewhat painful, as you had to do a lot of XML parsing which created large packet payloads traversing the network, thus using up a considerable amount of bandwidth for high-traffic services. Each packet payload was wrapped in a SOAP envelope containing a service request or response. It worked well (and still does), but isn't very intuitive, making it harder to learn or work with the service.
Ruby Inspires the RESTful Concept
When Ruby on Rails became popular, it was quickly noticed how well a Ruby application could be browsed for information. Browsing a Ruby application was similar to browsing the web, and soon after vendors started adding the RESTful architecture for web services to their development frameworks. The concept of browsing application resources came from the World Wide Web architecture for browsing resourcesan intuitive, easy-to-understand architecture with which most people are familiar.
With Ruby, you browse the application using the Model/Action/Input syntax. The Model are the nouns in your application (i.e., Book, Customer). The Action is what to do with the Model (i.e., show information), and the Input is the resource (Model) id. For example, to show information on a book with an id of 12, you could do the following with a Ruby application (http://myRubyapp.com/book/show/12). Getting access to the resource and what we want do with it is much more intuitive than some long URL that makes no sense other than we know to visit there (or the application does) to perform an action on a resource.
When you browse the web, you give a domain name followed by a path to the resource on that host. If the website is set up in a logical manner, you will have similar pattern (i.e., http://mathcalcs.com/calc/add). The RESTful concept uses this pattern for browsing service resources, making it HTTP-centric. Each resource path is referred to as a URI (uniform resource indicator).