1 Introduction to RESTful Web Services
RESTful web services are Jakarta Enterprise web services that you develop to conform to the Representational State Transfer (REST) architectural style using Jakarta RESTful Web Services (JAX-RS).
Introduction to the REST Architectural Style
REST is an architectural style for distributed hypermedia systems. For HTTP-based services, resources are identified by URIs and accessed through a uniform interface. Clients and servers exchange representations and metadata about resources; an HTTP response need not contain a representation.
A client sends a request that identifies a resource and states the requested operation. When a message contains a representation, it can convey the resource's current state or a proposed new state. REST also constrains how clients, servers, and intermediaries interact, as summarized in Table 1-1.
Table 1-1 summarizes the REST architectural constraints. Code on demand is optional; the other listed constraints define the style.
Table 1-1 Constraints of the REST Architectural Style
| Constraint | Description |
|---|---|
| Client-server | Separate client concerns from server concerns so each can evolve independently. |
| Stateless | Each client request contains the information needed to process it; the server does not rely on stored client session context between requests. |
| Cache | Responses indicate whether their data can be reused for equivalent later requests. |
| Uniform interface | Identify resources, manipulate them through representations, use self-descriptive messages, and guide application state through hypermedia. HTTP methods are one way an HTTP-based service expresses this interface. |
| Layered system | A component interacts through its adjacent layer without needing to know whether an intermediary or origin server handles the request. |
| Code on demand (optional) | A server may extend client functionality by transferring executable code, such as scripts; REST does not require this feature. |
What are RESTful Web Services?
RESTful web services are services that are built according to REST principles and, as such, are designed to work well on the Web.
RESTful web services conform to the architectural style constraints defined in Table 1-1. Typically, RESTful web services are built on the HTTP protocol and implement operations that map to the common HTTP methods, such as GET, POST, PUT, and DELETE to retrieve, create, update, and delete resources, respectively.
Standards Supported for RESTful Web Service Development on WebLogic Server
The Jakarta RESTful Web Services specification provides support for creating web services according to REST architectural style. Jakarta RESTful Web Services use annotations to simplify the development of RESTful web services. By simply adding annotations to your web service, you can define the resources and the actions that can be performed on those resources.
Jakarta RESTful Web Services 4.0 is a required component of both the Jakarta EE 11 Web Profile and the full Jakarta EE 11 Platform. It integrates with Jakarta Contexts and Dependency Injection (CDI), Jakarta Enterprise Beans (EJB), and Jakarta Servlet.
WebLogic Server 26.1.0.0.0 supports the following Jakarta RESTful Web Services specification:
-
Jakarta RESTful Web Services 4.0
-
Jersey 4.0.0
Note:
Jersey support is provided by default in this release of WebLogic Server. Registration as a shared library is no longer required.
Jersey includes the following functionality:
-
Jersey
-
Jakarta RESTful Web Services
-
JSON processing and streaming
Table 1-2 lists key features delivered with Jersey.
Table 1-2 Key Features in Jersey
| Key Feature | Description |
|---|---|
|
Client API |
Communicate with RESTful web services in a standard way. The Client API facilitates the consumption of a web service exposed via HTTP protocol and enables developers to concisely and efficiently implement portable client-side solutions that leverage existing and well established client-side HTTP connector implementations. For complete details, see:
|
|
Asynchronous communication |
Invoke and process requests asynchronously. For complete details, see:
|
|
Filters and interceptors |
Using filters, modify inbound and outbound requests and responses, such as header information. Using interceptors, modify entity input and output streams. Filters and interceptors can be used on both the client and server side. For complete details, see Filters and Interceptors in the Jersey User Guide. |
For more information about JAX-RS and samples, see Learn More About RESTful Web Services.
Roadmap for Implementing RESTful Web Services
Table 1-3 Roadmap for Implementing RESTful Web Services and Clients
| Task | More Information |
|---|---|
|
Develop RESTful web services. |
|
|
Develop clients to invoke the RESTful web services. |
|
|
Package and deploy RESTful web services. |
|
|
Secure RESTful web services. |
|
|
Test RESTful web services. |
|
|
Monitor RESTful web services. |
|
|
(Optional) Migrate existing applications from earlier Jersey versions. |
Migration Guide in Jersey User Guide |
Learn More About RESTful Web Services
Table 1-4 Resources for More Information
| Resource | Link |
|---|---|
|
Jersey User Guide |
|
|
Jersey API Javadoc |
|
|
Community Wiki for Project Jersey |
|
|
Jakarta RESTful Web Services Specification |
|
|
JAX-RS API Javadoc |
|
|
JAX-RS Project |
|
|
RESTful Web Services (JAX-RS) sample |
Sample Application and Code Examples in Understanding Oracle WebLogic Server. |
|
The Jakarta EE Tutorial: Building RESTful Web Services With JAX-RS |
|
|
"Representational State Transfer (REST)" in Architectural Styles and the Design of Network-based Software Architectures (Dissertation by Roy Fielding) |
|