Skip to end of metadata
Go to start of metadata

This article takes you through some of basic concepts about RESTful Web Services.

What is REST?

The acronym REST stands for Representational State Transfer, which basically means that each unique URI is a representation of some object and an action executed upon it.

URI & URL

Icon

URI (Uniform Resource Identifier) is used throughout this tutorial. If it makes you feel better, cross it out and use URL instead.

In the Web services world, Representational State Transfer (REST) is a key design idiom that embraces a stateless client-server architecture in which the Web services are viewed as resources and can be identified by their URIs. Web service clients that want to use these resources can get a content of using HTTP GET, modify the content using HTTP POST or HTTP UPDATE or delete the resource using HTTP DELETE.

REST - An Architectural Style, Not a Standard

Icon

REST is not a standard. You will not see the W3C putting out a REST specification. Because REST is just an architectural style. You can design your Web services in that style by understanding it.

RESTful Web services

Systems which follow REST principles are often referred to as RESTful. RESTful Web services is one among them and simplifies the development of Web services when compared to SOAP Web Services. Today, the Java API for XML Web Services (JAX-WS) provides basic support for building and deploying RESTful Web services. However, the upcoming Java API for RESTful Web Services (JAX-RS) specification will provide the full support for RESTful Web Services for the Java platform.

XML message level

In RESTful Web services applications commonly work at XML message level which unlocks full potential of utilizing the Web service. Although this has a downside by increasing complexity of client applications, compared to the significant ease of developing services its just a very little bump on the road. JAX-WS provides a generic Provider and Dispatch interface to access the message payload using low level API.

REST advantages

  • The Web Services are completely stateless
  • Light weight
  • No security issues with firewalls
  • Human readable results
  • Relative ease and reduction in time to develop services.

Security Issues

Icon

As firewalls don't understand the meaning of SOAP messages, they never let those messages pass whereas REST messages don't have this problem because they only use what is specified in HTTP standard.

And REST is definitely the trendy way to develop Web services if creating Web services could ever be trendy.

World Wide Web

The World Wide Web is the key example of RESTful design. Much of it conforms to the REST principles. REST itself draws much of its design from the current design of World Wide Web to be compatible with it.

Tools to develop REST

This is the area where REST is stumbling by a lack of companies to support development of REST. Since REST services are easy to build, theoretically any HTTP-compliant tool could be used to develop them. In Java, the JAX-WS specification provides adequate support for REST Services to develop and consume.

Who are using REST?

RESTful Web Services isn't some obscure thing that is introduced in this tutorial. It has already got plenty of support from many companies. A few listed are:

  • Yahoo! - All Yahoo API's Web Services uses REST including Flickr, etc.
  • Google - Google Adsense Search and Google Maps are two good examples for RESTful services implemented by Google
  • Amazon
  • EBay
  • del.ico.us

Many other companies admire REST Services and the list will be pretty big if each and every company were listed.

Icon

If you want to know when to use REST services and when to use SOAP ones, you can refer to the following link for a better understanding http://java.sun.com/developer/technicalArticles/WebServices/restful/

Future

RESTful Web Services have recently been introduced when compared to SOAP Web services which are sufficiently well established. In addition, the future holds the possibility of describing RESTful Web services for tools to consume, which will further simplify the developer's experience.

Labels
  • No labels