|(13 intermediate revisions by 3 users not shown)|
|−|This document acts as the project proposal for the 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 = |+|
| || |
RESTbased to access http , , and .
|−|Many service providers using a REST based API to offer developers access to their services, i.e. [http ://apiwiki.twitter.com/ Twitter], [http://developers.facebook.com/?ref=pf Facebook] and so on. The result of this is that some third parties provide Java based libraries, which covers this API's. The [[Eclipse_Communication_Framework_Project|ECF]] team played a little bit with the Twitter API and use therefore a library called [http://yusuke.homeip.net/twitter4j/en/index.html Twitter4J]. <br>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 [http://socghop.appspot.com/ GSoC] project. |+|
| || |
|−|==How does it fit in the ECF context?== |+|
ECF to . e., for REST.
|−|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 [http:/ /hc.apache.org/httpclient-3.x/ Jakarta HTTP Client], the [http://www.innovation.ch/java/HTTPClient/ innocation.ch HTTP Client] or others.<br> |+|
|−|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 .: [http://...////..........and .
|−|The Representational State Transfer is not a technology; it’s more a technique to use the web correctly. REST defines three different element types: |+|
|−|* Components |+|
|−|* Connectors |+|
|−|* Data |+|
|−|For a full definition of REST take a look at [http:// www. ics. uci. edu/ ~fielding/ pubs/ dissertation/ rest_arch_style. htm Roy Fielding’s Dissertation]. <br> |+|
|−|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. <br> |+|
|−|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 of , :.'.
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.<br><br> |+|
|−|'''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) |+|
| || |
|−|* [http:// www. ics. uci.edu/ ~fielding/ pubs/ dissertation/ rest_arch_style. htm Fielding’s definition of REST] |+|
ECF's focus has been the support of OSGi remote services...i.e. exposing OSGi services remotely, via proxies that have underneath them some protocol for communicating with the actual remote service.
REST-based services use http to access remote resources via http get, put, post, and delete actions.
The ECF REST abstraction allows REST-based services to be exposed to clients/consumers as OSGi services. This allows the automatic use of a number of useful technologies based upon OSGi services (e.g. declarative services, spring, ServiceTracker, etc) for accessing REST-based services.