EG tel-con meeting 24th April 2007 (DRAFT) Present ----------- Jan Algermissen Bill de Hora Larry Cable Roy Fielding Marc Hadley Mark Hansen Ryan Heaton Dave Hensley Julian Reschke Paul Sandoz Minutes ----------- 1. Round table of introductions and primary interests There was general consensus around the primary interests expressed by EG members on the need for a high-level API that is simpler than the Servlet API or the JAX-WS API for the development of RESTful Web services in Java. Phrases like "make the simple things really simple" and the "hard things possible" were commonly expressed or concurred with. 2. Discussion of goals 2.1 POJO-based General agreement on this goal. It is the 'programming style de jure'. 2.2 HTTP centric. There was general agreement on the following: - expose HTTP to the extent it makes sense but not build abstractions that get in the way. - HTTP is the 80% and should be well-integrated into the programming model. - the runtime should provide support for common cases (like content negotiation and caching support) but still provide full access to everything that HTTP provides (sans low-level container-specific aspects) as we can never be sure what developers will want to do. - names of annotations/classes/ifaces can be abstract from HTTP but need to provide clarity and limit conflicts with names commonly used in other contexts. The relationship to HTTP can be specified in the Java documentation. - design for existing HTTP usage (which includes existing protocols that extend HTTP, such as WebDAV) and not for future protocols that extend and/or improve on HTTP. It is easier to design for now and modify in the future. 2.3 Format independence There was general agreement that this API should not tie itself to XML. JSON, forms, N3, images, audio and video are other useful formats. It was expressed that sketch 2 of the API provides a good way to go in this respect. 2.4 Container independence General consensus that the API (and hence applications developed using it) should be independent of container. Portability of API implementations between containers is felt to be less important. A question was raised about lack of features in the servlet API, for example the lack of support for 100 (Continue) responses. We need to work with the Servlet EG to identify requirements and use-cases lacking in the servlet API that we require for support as a container. 2.5 Inclusion in Java EE 6 General agreement. It was expressed that the current thinking is to provide something similar to that of JSF managed beans. 3. Discussion of non-goals 3.1 Client APIs General agreement. 3.2 No new HTTP stack. General agreement. 3.3 Data model/format classes General agreement. 4. Other goals/non-goals No other proposed goals/non-goals were presented by EG members. 5. Points of note during the meeting A question was asked how educational the API should be. The specification should be terse and, well, spec-like, but the Java documentation should be helpful and there is scope for good examples of using the APIs. It was noted that there are one or two EG members that are authors and that their experience in this area will be most helpful. It was observed that an API cannot be RESTful itself, rather the applications built using the API can be RESTful. There was general agreement that the API should lead in a certain direction where developers would 'naturally' build RESTful applications. 6. Attending Java one. Larry Cable, Marc Hadley, Dave Hensley and Paul Sandoz will be attending Java One. We should meet and have a beer or two and amongst other things discuss this API. A session on this JSR will be presented by Marc Hadley and Paul Sandoz: Session ID: TS-6411 Session Title: JSR 311: The Java API for RESTful Web Services Track: The Next Generation Web Room: Esplanade 307-310 Date: 08-MAY-07 Start Time: 18:00 7. EOM.