Function Comparison of Jakarta RESTful Web Services Support /Jakarta RESTful Web Services/HTTP Messaging

This section shows the comparison of the following functions:

Tip

Only for Nablarch’s Jakarta RESTful Web Services support and HTTP messaging only, click the mark in the table to jump to the description page of the manual.

Function comparison (A: Provided B: Partially provided C: Not provided D: Not applicable)
Function Jakarta RESTful
Web Services
support
HTTP
messaging
Jakarta RESTful
Web Services
Request and resource method mapping B A A
Mapping of request and resource method B C [1] A
Mapping of HTTP method B C [1] A
Convert request/response
according to the media type
B C [1] A
Entity validation A A A
Injection to resource class
(Jakarta Contexts and Dependency Injection)
C [2] C [2] A
Filter for request/response C [3] C [3] A
Interceptor for reading and writing the body C [4] C [5] A
Client API C [6] A A
Asynchronous operation C [7] C [7] A
Error log output A A D
Checking the maximum capacity of the request body C [8] A D
Output of the trace log C [9] A D
Retransmission control C [9] A D
Service availability check C [10] C [10] D
Transaction control C [11] C [11] D
Callback on business process errors C [12] A D
[1](1, 2, 3) HTTP messaging is not designed in consideration of REST. Use Jakarta RESTful Web Services support for RESTful web services.
[2](1, 2) Jakarta Contexts and Dependency Injection is not available because Jakarta RESTful Web Services support and HTTP messaging run as Nablarch web applications.
[3](1, 2) Create a handler for creating a request/response filter.
[4]Create a BodyConverter with Jakarta RESTful Web Services support for creating an interceptor to read and write the body.
[5]Use data format of Nablarch to read and write the body. Create a DataRecordFormatter to change the data format.
[6]If Jakarta RESTful Web Services client is needed, use a Jakarta RESTful Web Services implementation (such as Jersey or RESTEasy).
[7](1, 2) It is assumed that asynchronous operation in the server is not required. Support will be considered if there is a request.
[8]Use the function to check the request size on the web server or application server.
[9](1, 2) Each application is assumed to have different requirements. Design/implement in the application.
[10](1, 2) If a service availability check in Nablarch matches the application’s requirements, use the check. If a check does not match, design/implement the check in the application.
[11](1, 2) Use the transaction management available in Nablarch.
[12]Error handling is assumed to be common and JaxRsResponseHandler is assumed to be customized. To handle errors individually in business operations, use try/catch in resource methods.