 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 311: JAX-RS: The JavaTM API for RESTful Web Services
Updates to the Java Specification Request (JSR) The following information has been updated from the original JSR:
2011.05.01: Maintenance Lead: Marek Potociar E-Mail Address: marek.potociar Telephone Number: +420 72 477 4838 Fax Number: - 2011.02.22:Maintenance Lead: Roberto Chinnici E-Mail Address: roberto.chinnici Telephone Number: +1 415 402 7873 Fax Number: +1 415 402 7215 2008.04.25: Pursuant to Section 2.2.1 of the Java Community Process version 2.6, the following is a summary of Sun's anticipated principal license terms and conditions for JSR 311, JAX-RS: The Java API for RESTful Web Services. The JAX-RS Technology Compatibility Kit (TCK) will be available both as a standalone TCK and included as part of the Java EE 6 Compatibility Test Suite (CTS). The JAX-RS Reference Implementation (RI) will be available both separately and as part of the Java EE 6 RI. The TCK license does not limit how a compatible implementation of the specification can be used or distributed, e.g., by limiting the hardware devices or operating environments that can be supported. Non-Commercial Use As required by the Java Specification Participation Agreement (JSPA), the JAX-RS TCK will be licensed at no charge without support to qualified not-for-profit entities. Such qualification will be verified by the Compatibility Testing Scholarship Program. Support may also be provided at no charge with approval of the scholarship board. For more information, please refer to: http://java.sun.com/scholarship/. The RI will be available at no cost under an open source license. Commercial Use Covers all use that doesn't fall under "Non-Commercial Use" above. JAX-RS Java Licensee Engineering (JLE) support, available for a fee not to exceed $50k, is required for commercial use for each Marketed Product* which implements the JAX-RS specification. TCK JLE support includes access, updates and upgrades to the TCK at no additional charge. JAX-RS RI and TCK JLE and marketing support will be made available at no extra charge to Java EE licensees under their Java EE business terms. The RI will also be made available at no cost under an open source license for commercial use. For purposes of these terms: *Marketed Product is intended to describe a licensee's product that has its own differentiation and marketing collateral. It may comprise one price list entry, or in some cases multiple entries (for example, to account for different localizations or delivery packaging). By way of example, in terms of Sun's product line we wouldn't consider Sun's Java Application Server to be a Marketed Product, but Sun's Java Application Server Platform Edition, Standard Edition, and Enterprise Edition are 3 Marketed Products. Sun's Java Studio Enterprise is a fourth Marketed Product. The following has been updated from the original proposal.
2007.04.05:
2.18 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.The Reference Implementation will be made available from java.sun.com at no charge without support. The reference implementation will be of production quality and will be developed using the open source development model. Java SE and Java EE licensees will receive support at no extra charge with an amendment to their active support agreement. Source code will be made available under the same terms as Project GlassFish, currently licensed under CDDL and soon to be licensed under GPLv2 as well.Sun will license the standalone TCK for this JSR for our standard fee for individual technologies The TCK source will be made available at no extra charge to J2EE licensees. In addition, the TCK will be licensed at no charge, without support or any trademark license rights under Sun's Compatibility Testing Scholarship Program, described at http://java.sun.com/scholarship/. Original Java Specification Request (JSR)
Identification |
Request |
Contributions |
Additional Information
Section 1. Identification Submitting Member: Sun Microsystems, Inc Name of Contact Person: Rajiv Mordani E-Mail Address: rajiv.mordani Telephone Number: +1 408 276 7204 Fax Number: +1 408 276 7191 Specification Lead: Marc Hadley, Paul Sandoz E-Mail Address: marc.hadley Telephone Number: +1 603 488 0564, +33 4 76 18 81 09 Fax Number: +1 408 276 7191 NOTE that this information has been updated from this original proposal. Initial Expert Group Membership: Apache Supporting this JSR: Apache Section 2: Request
2.1 Please describe the proposed Specification:This API will enable developers to rapidly build Web applications in Java that are characteristic of the best designed parts of the Web. This JSR will develop an API for providing REST(Representational State Transfer - See reference to Roy Fielding's dissertation in section 3.1) support in the Java Platform. Lightweight, RESTful approaches are emerging as a popular alternative to SOAP-based technologies for deployment of services on the internet. Currently, building RESTful Web services using the Java Platform is significantly more complex than building SOAP-based services and requires using low-level APIs like Servlets or the dynamic JAX-WS APIs. Correct implementation requires a high level of HTTP knowledge on the developer's part. This JSR will aim to provide a high level easy-to use API for developers to write RESTful web services independent of the underlying technology and will allow these services to run on top of the Java EE or the Java SE platforms. The expert group will investigate whether a subset of the API can be made used with Java ME. The goal of this JSR is to provide an easy to use, declarative style of programming using annotations for developers to write REST ful Web Services and also enable low level access in cases where needed by the application. RESTful Web Services is a relatively new area in the industry and there are still a lot of unknowns in this space. For example, a key aspect of RESTful Web Services is for the service to be stateless. However, this often requires the developer to produce boiler-plate state restoration code that could be avoided with state-aware API help. We expect the expert group to be an active and engaged group of people participating to prioritize and help drive issues to achieve the end goal of a developer friendly API. 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)This specification is targeted for J2SE 5.0 or higher and Java EE 5 or higher platforms. The expert group will investigate whether a subset of the API can be made to be used with Java ME. 2.3 The Executive Committees would like to ensure JSR submitters think about how their proposed technology relates to all of the Java platform editions. Please provide details here for which platform editions are being targeted by this JSR, and how this JSR has considered the relationship with the other platform editions.This JSR is targeted for inclusion in a future release of Java SE and Java EE platforms. A subset of this JSR could also be included in a future release of Java ME. 2.4 Should this JSR be voted on by both Executive Committees?No. SE/EE EC 2.5 What need of the Java community will be addressed by the proposed specification?See 2.1 2.6 Why isn't this need met by existing specifications?The APIs currently available for the development of RESTful services are too low-level and require a deep understanding of HTTP issues and design patterns. We need to enable developers to write these services easily. 2.7 Please give a short description of the underlying technology or technologies:The specification would depend on JSR 175(A Metadata Facility for the Java(TM)Programming Language) and hence J2SE 5.0. The specification will define how RESTful services are deployed as JAX-WS (Java API for XML Web Services) endpoints or Servlets. 2.8 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)javax.ws.rest 2.9 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?No 2.10 Are there any security issues that cannot be addressed by the current security model?No. This JSR will leverage existing HTTP security mechanisms. 2.11 Are there any internationalization or localization issues?This JSR will use the I18N support in J2SE. 2.12 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?Servlets (JSR 154) and JAX-WS (JSR 224) will probably need some revisions to enable better support for the API. Also the intent is to include this API in future revisions of the Java SE and Java EE platforms as well. 2.13 Please describe the anticipated schedule for the development of this specification.We hope to deliver the final specification, reference implementation, and TCK in CY08. A rough schedule would be:
2.14 Please describe the anticipated working model for the Expert Group working on developing this specification.The primary means of communication will be email, with conference calls and face-to-face meetings scheduled as needed. We will solicit feedback from the community and leverage the open source development model. 2.15 It is important to the success of the community and each JSR that the work of the Expert Group be handled in a manner which provides the community and the public with insight into the work the Expert Group is doing, and the decisions that the Expert Group has made. The Executive Committees would like to ensure Spec Leads understand the value of this transparency and ask that each JSR have an operating plan in place for how their JSR will address the involvement of the community and the public. Please provide your plan here, and refer to the Spec Lead Guide for a more detailed description and a set of example questions you may wish to answer in your plan.We will solicit feedback from the community and leverage the open source development model. 2.16 Please describe how the RI and TCK will de delivered, i.e. as part of a profile or platform edition, or stand-alone, or both. Include version information for the profile or platform in your answer.The reference implementation will be made available via the Java SE and Java EE platforms as well as standalone. The TCK will be made available standalone as well as part of the CTS and JCK where applicable. 2.17 Please state the rationale if previous versions are available stand-alone and you are now proposing in 2.13 to only deliver RI and TCK as part of a profile or platform edition (See sections 1.1.5 and 1.1.6 of the JCP 2 document).N/A. 2.18 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.NOTE that this information has been updated from this original proposal. The Reference Implementation will be made available from java.sun.com at no charge without support. The reference implementation will be of production quality and will be developed using the open source development model. Java SE and Java EE licensees will receive support at no extra charge with an amendment to their active support agreement. Source code will be made available under the same terms as Project GlassFish, currently licensed under CDDL and soon to be licensed under GPLv2 as well. Note that this information has been updated from the original JSR. Section 3: Contributions
3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.Java Platform, Enterprise Edition Specification 5,
and related specifications
Java 2 Platform, Standard Edition, v5.0 API Specification
JSR-154 Java Servlet Specification
2.0 JSR-224 Java APIs for XML based Web Services
2.0 JSR-244 Java Platform, Enterprise Edition Specification Version 5 3.2 Explanation of how these items might be used as a starting point for the work.N/A Section 4: Additional Information (Optional)
4.1 This section contains any additional information that the submitting Member wishes to include in the JSR.
|
