Rest server library

The rest server library ([../tree/master/library/server/rest]) provides "an" implementation for RESTful service. It is still work in progress, and the interface are likely to change in the near future, especially the part related to request handler mapping. It tries to be as flexible as possible, to allow any kind of RESTful services: true RESTful service using CRUD (CreateReadUpdateDelete) and also pseudo RESTful service but sometime easier to integrate (such as Twitter API).

As you can see on following diagram, there is a deferred class REST_APPLICATION ([../tree/master/library/server/rest/interface/rest_application.e]) which provides implementation for the request handler manager REST_REQUEST_HANDLER_MANAGER ([../tree/master/library/server/rest/handler/rest_request_handler_manager.e]). This manager is controlling the mapping between a url and a request handler REST_REQUEST_HANDLER ([../tree/master/library/server/rest/handler/rest_request_handler.e]).

To build a REST request handler:

• You need to create the associated class which implements a descendant of REST_REQUEST_HANDLER
• it should provide implementation for `execute_application (...)' , `authentication_required: BOOLEAN'
• and you are free to redefine for instance `initialize' to be able to precise which request method is supported, which parameters are expected (this is mainly to enable auto-documentation, but this can also be used for validity checking), which format is supported and so on.

to register the handler mapping:

• in the REST_APPLICATION implementation, you need to "register" the various handler with a path (or uri in the future).

Notes:

• The `execute_application' method provides 3 arguments, the request context, the requested format if any (json, xml, ...)and the arguments string.
• Currently the implementation is working, but it is likely to change to provide a better handler mapping using URI template. The way the requested format is detected might also be updated to use the Content-type provided in the HTTP request, currently it is based on the .{format} convention.

For example:

• For /api/test.json/foo/bar, we can create APP_TEST inheriting REST_REQUEST_HANDLER, and registered for path /api/test/.
• At request execution time, the format will be json, and the arguments foo/bar. If ever you want to use another convention such as /api/test/foo/bar.json, you need to call {REST_REQUEST_HANDLER}.set_format_located_after_parameters. However this should change when we'll add support for URI template, and if we use the Content-type value, there is no need for the .{format} information.

For more information please have a look at the examples-rest_server.

Diagram