Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

ECF/REST abstraction

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.


Committer Lead: Holger Staudacher (IRC: staudi)

Other participating committers: Scott Lewis, Marcelo Mayworm

This project started as part of the Google Summer of Code 2009

Abstract

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.

RESTabstraction2.png

REST use HTTP to communicate between client and server. So a coupling to a HTTP Client is necessary. The HTTP connections can be realized by an implementation of the ECF Remote Services API.
This implementation would be used by the REST abstraction to realize the basic communication. 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:

  • Components
  • Connectors
  • Data

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.

Primary goals

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:

  • A full working API for the REST client side to communicate to any RESTful web service.
  • Implementation of the ECF Remote Services API.
  • 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)

Getting the source

See the appropriate project set below.

Project set file for anonymous CVS access:

<?xml version="1.0" encoding="UTF-8"?>
<psf version="2.0">
  <provider id="org.eclipse.team.cvs.core.cvsnature">
    <project reference="1.0,:pserver:anonymous@dev.eclipse.org:/cvsroot/rt,org.eclipse.ecf/framework/bundles/org.eclipse.ecf.remoteservice.rest,org.eclipse.ecf.remoteservice.rest"/>
    <project reference="1.0,:pserver:anonymous@dev.eclipse.org:/cvsroot/rt,org.eclipse.ecf/framework/bundles/org.eclipse.ecf.tests.remoteservice.rest,org.eclipse.ecf.tests.remoteservice.rest"/>
    <project reference="1.0,:pserver:anonymous@dev.eclipse.org:/cvsroot/rt,org.eclipse.ecf/incubation/bundles/org.json,org.json"/>
  </provider>
</psf>

These projects depend upon relatively new code in the ECF sdk. A project set file for all ECF projects can be found here or via the ECF releng project at

Protocol: pserver

Host: dev.eclipse.org

CVS Root: /cvsroot/rt

Module: org.eclipse.ecf/releng/org.eclipse.ecf.releng

Or see this page for instructions on getting the ECF releng project.

Test/Example code

See the test cases in org.eclipse.ecf.tests.remoteservice.rest. Particularly the test classes: org.eclipse.ecf.tests.remoteservice.rest.RestRemoteServiceTest and org.eclipse.ecf.tests.remoteservice.rest.twitter.TwitterRemoteServiceTest.

New ideas

Please open a new feature request.

Javadocs

Documentation is available in org.eclipse.ecf Javadoc API. The REST API is in these packages:

  • org.eclipse.ecf.remoteservice.rest
  • org.eclipse.ecf.remoteservice.rest.client
  • org.eclipse.ecf.remoteservice.rest.identity
  • org.eclipse.ecf.remoteservice.rest.util

Weblinks/Literature

Back to the top