0 Replies Latest reply on Feb 26, 2016 1:40 PM by cfang

JBeret Rest API, JAX-RS and RESTEasy

cfang Feb 26, 2016 1:40 PM

jberet-rest-api (jsr352/jberet-rest-api at master · jberet/jsr352 · GitHub) module was recently added to jberet project to provide an HTTP API for clients. It should provides more means for various clients to interact with the server JBeret runtime, for instance,

tests for batch webapp can use JAX-RS client side API to directly access batch resources via JBeret REST API. No more need for a test servlet in the middle. Our REST API test app, jsr352/test-apps/restAPI at master · jberet/jsr352 · GitHub uses this approach. wildfly-samples/jberet at master · chengfang/wildfly-samples · GitHub still uses servlet and ad hoc query parameters to communicate batch request info, and could be simplified using the new jberet-rest-api.
request can be submitted vaious tools that support HTTP, which is useful during development and manual testing/debug
- command line tools like curl, httpie
- browser
- REST client tools from IDE, and browser extension
from javascript in web pages
from other types of applications, possibly written in other languages, that support HTTP as a communication protocol

The REST API docs based on the initial impl (work in progress):

http://docs.jboss.org/jberet/1.3.0.Alpha1-SNAPSHOT/rest-api/

http://docs.jboss.org/jberet/1.3.0.Beta1-SNAPSHOT/rest-api/

Some points for discussion:

Currently jberet-rest-api mirros all methods in JobOperator interface (except javax.batch.operations.JobOperator#getJobInstance). In the future, we may want to expand into more operations that are not in JobOperator. In addition, some JobOperator methods are too fine-grained not best fit for remote access, and we should think about whether to support them in REST API.
How to deal with versioning, should we include versioning info MediaType in HTTP Accept header, or embed it in URL? URL approach is easier for users and more popular, and the header approach seems more of pure REST style.
How to deal with cross origin resource sharing (CORS)? This issue only applies for applications where its front-end and back-end run in different host and port combination. Browsers by default will not allow cross origin access. Currently we include a JAX-RS filter to add 2 headers to all response to explicitly allow CORS, which may compromise securities. In a secure runtime environment, this filter should probably be removed and proxy be set up to handle CORS issue.
Currently jberet-rest-api only depends on batch api, with no dependecy on any impl classes. But if we want to support more operations beyong JobOperator, we need access to JobRepository, and hence the dependency on jberet-core module. Should be introduce this deps on jberet-core?

Resources: