REST Web Services in WebSphere Liberty
This chapter is from the book
This chapter is from the book
This chapter is from the book
What Is REST?
Earlier in Chapter 1, “The Modern Web,” and again in Chapter 3, “Design,” we discussed the REST approach to building web services. REST is about creating web services around a set of constraints. By sticking to the constraints that stem from the way the web was designed and built, you can take better advantage of the existing web infrastructure. Routers, caching proxies, and web servers are all optimized to deliver web content. Delivering your services as web content through these channels enables you to take advantage of existing optimizations in these channels.
The philosophy of RESTful services construction has two parts. One part centers on exposing resources, putting them into the hands of the masses and then allowing others in the community to create new types of applications by mixing and matching content from various places. In our context, you can view REST services as the data source for your model layer inside a Modern Web Application that runs in the browser or as a mobile app. REST services can provide data for reusable widgets that you can mix together to create mashups. REST services can also present data as feeds, notifying end users of content through the use of feed readers.
In general, almost any data—including business logic—can easily be expressed through REST. What’s more, it’s easy to build REST services that provide content in different forms (for instance, JSON and XML). For these reasons, REST services are extending into the API space and rapidly becoming accepted as the default standard for providing externally accessible web APIs. This services exposure for enabling reuse is a central part of the REST philosophy.
The second aspect of the REST philosophy focuses on using RESTful idioms to simplify access, increase orthogonality, and enable discovery. This is where the arguments tend to start. REST is based on a set of simple principles that derive from the HTTP specification and other web standards. Some developers tend to follow these principles very closely, whereas others are more lax in their compliance with the principles set forward in the original REST paper by Roy Fielding. In our examples, we tend toward a more strict interpretation of REST, but we do point out places where deviations might commonly occur.