(Ce n'est qu'une ébauche. Comme c'est un projet qui est amené à prendre de l'empleur, j'ai commencé à rédiger en anglais. Tout est modifiable.)

RFC: REST API protocols definition for l'ouvre-boîte

Preamble

L'ouvre-boite is planning to leverage the resources of his team members to quickly prototype new and innovative Internet services. Each member, making use of his own resources, may propose an implementation of a service he think is useful to the community.

Programming languages being so diverse and programming habit being hard to change, it is easier at this point of time to let each member develop in his own language and offer the service as a web service. Decision has been made to use the REST architecture to allow interoperability.

To make is process as efficient as possible, it seems useful to have a common set of API between services.

  • It is easier to use multiple services with a single syntax
  • It is easier to mix and match data coming from different services
  • A set of "best practices" can be built among the members.
  • ...

Definitions

This RFC uses the following conventions:

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119

Current resources

Referring to Atom REST Api could be a good thing given the current momentum around Atom, we could build on the current tools developed for it like the universal feed parser…

Existing services

del.icio.us

URL: http://del.icio.us

Api doc: http://del.icio.us/doc/api

Nouns:

  • tag/(tagname)
  • doc
  • (username)
  • rss/(username)
  • rss/tag/(tagname)
  • rss/tag/(username)/(tagname)
  • popular

BlogMarks

URL: http://blogmarks.net/

Api doc: http://dev.blogmarks.net/cgi-bin/blogmarks.cgi/wiki/DeveloperDocs Nouns:

  • tag/(tagname)
  • user/(username)

6nergie

http://www.6nergies.net/

Based on Horde, Agora, PhpBb

No Api found yet.

Viabloga

http://www.viabloga.com

No Api found yet

RFC for REST at l'ouvre-boite

Definition of the basic verbs

  • POST = create resource from XML entity
  • PUT = rewrite resource from XML entity
  • GET = get XML representation of resource
  • DELETE = delete resource
Categorize your resources according to whether clients can just receive a representation of the resource, or whether clients can modify (add to) the resource. For the former, make those resources accessible using an HTTP GET. For the later, make those resources accessible using HTTP POST, PUT, and/or DELETE.

WSDL (Web Service Description Language) ?

URIs

  • MainURL for the service is of the form http://www.mynicedomain.com/directory
  • /rest main service URL
  • /rest/methods machine readable documentation for supported methods
  • /rest/error Human readable error message
  • /rest/doc Human readable documentation
Nouns:
  • /ver[0-9].[0-9]/ version of the service.

Status codes

Data representation

Data is return as XHTML or XML based on content negotiation between the Web server and the User Agent. It may be useful to have an human readable (XHTML) representation of the data as an alternative to the machine parsable (XML) representation.

Base types

I suggest the use of the XML-RPC representations. This allow to leverage existing libraries for encoding and decoding simple transactions. Even Ruby has one : http://www.ruby-doc.org/stdlib/libdoc/xmlrpc/rdoc/

Complex types

  • All text MUST be in UTF-8.
  • Dates MUST be in ISO8601
MIME

gzip