Difference between revisions of "ECF/REST abstraction"
|Line 1:||Line 1:|
This document acts as the project proposal
This document acts as the project proposal GSoC project: [http://wiki.eclipse.org/Google_Summer_of_Code_2009_Ideas REST abstraction for ECF] and was created by [http://eclipsesource.com/blogs/author/hstaudacher/ Holger Staudacher] for his GSoC application. This is a living document. Feel free to edit or add things.<br><br><br>
=REST abstraction for ECF=
=REST abstraction for ECF=
Revision as of 11:09, 25 March 2009
This document acts as the project proposal for the GSoC project: REST abstraction for ECF and was created by Holger Staudacher for his GSoC application. This is a living document. Feel free to edit or add things.
REST abstraction for ECF
Many service providers using a REST based API to offer developers access to their services, i.e. Twitter, Facebook and so on. The result of this is that some third parties provide Java based libraries, which covers this API's. The ECF team played a little bit with the Twitter API and use therefore a library called Twitter4J.
The disadvantage of this technique is a dependency to the third parties library. This means an ECF container based on such a library is dependent on the diversity of this. To decouple these dependencies an own ECF based REST abstraction should be created within this GSoC project.
How does it fit in the ECF context?
The Eclipse Communication Framework use containers for the connections to different systems. Many service providers i.e. Twitter, Facebook and so on provide their API’s over REST. Instead of using a different library for each, ECF will use the REST abstraction to realize the provider’s service. The integration can look like this.
REST use HTTP to communicate between client and server. So a coupling to a HTTP Client is necessary. The HTTP Client can be the Jakarta HTTP Client, the innocation.ch HTTP Client or others.
To use different Clients a layer between the REST abstraction and the HTTP Client would be the best because with this technique every HTTP Client can be used. The abstraction itself can be a set of classes, which provides the basic REST functionality. On top of this many different ECF Containers can be created easily.
The REST abstraction
The Representational State Transfer is not a technology; it’s more a technique to use the web correctly. REST defines three different element types:
For a full definition of REST take a look at Roy Fielding’s Dissertation.
The type, which is most important for this project, is data because data contains the resource. A resource is a basic REST concept. It’s a URL, which represents one web service. As REST use HTTP to send requests to a resource it uses the HTTP verbs: GET, POST, PUT, DELETE. If a client sends a request to a resource, the server answers with a resource representation. This representation can be a XML, HTML or RDF document i.e.
The REST abstraction constitutes an implementation of the REST definition focused on things needed by ECF (the client side). The most difficult part of this project is to figure out what REST based ECF containers really need and how to implement it usable and persistent.
There are some requirements for this project, which can be defined in this early state. Some are out of the project’s scope, but these can be completed after the GSoC project has finished.
In the project’s scope:
- Loose coupling to any HTTP Client.
- Lightweight implementation of the REST definition (client side).
- Resource abstraction to cover many resource representations (maybe over an extension point).
- Definition of REST requests
- Cover security issues (i.e. HTTP auth or HTTPS)
- Usable API documentation
- Test driven development
Out of project’s scope:
- Implementation of new ECF containers using the REST abstraction. This can be containers for Twitter, Facebook and so on.
- More resource representations (the exotics)