RESTx 0.9.4 release notes

Release date: August 31, 2010. Download RESTx-0.9.4.tar.gz or RESTx-0.9.4.zip. View the download and install instructions.

The following features have been implemented for the 0.9.4 release of RESTx:

Writing components in JavaScript: Components can now be written in server-side JavaScript. As usual, you can get started by just using the 'restxctl' utility to create an initial template of a JavaScript component for you. You can also see a documented example of a JavaScript component.

A JavaScript client library: RESTx uses a simple RESTful API to communicate with clients, which allows any HTTP capable client to interact with the RESTx server. But for your added convenience, some client libraries are provided. The 0.9.4 release adds a JavaScript client library. This means that you can now easily incorporate RESTx resources in your rich web applications. Examples are provided.

Proper handling of media types for input and output: A component's service methods can now declare the input and output media types they wish to accept/support. RESTx automatically performs all content negotiation with the client on behalf of the component, which means the component author can focus on other things. The allowable input media types and supported output types are shown in the automatically created RESTful API for the component and all its resources.

Miscellaneous fixes and improvements: Smaller bug fixes, improved exception handling and some cleanup.

RESTx 0.9.2 release notes

Release date: August 2, 2010. Download RESTx-0.9.2.tar.gz or RESTx-0.9.2.zip. View the download and install instructions.

The following features have been implemented for the 0.9.2 release of RESTx:

Specialized components: It is now possible to create specialized components. These are in effect partially defined resources, which - like components - can be used to create new resources. For example: A database access component may take a DB connection string and a query string as parameters during resource creation time. It is now possible for IT to create a specialized component resource by providing the DB connection string only. Users can then use this specialized component to create their resources. They may specify the query string, but the DB connection string is fixed and cannot be modified by the users. This is a great way for IT to quickly provide access to a number of resources, hiding parameters that are not relevant to users, while still allowing users to set the parameters they require.

Improved component import and control: The creation, import and handling of components has been greatly improved. It is now possible to use the restxctl script to not only create new components, but also to temporarily disable or enable them or to delete them and all related resources. Furthermore, components can be located in any directory or module and are not confined to the default locations anymore. The restxctl script also can show a list of all available components, their implementation language, their module and whether they are currently enabled.

Improvements to the component API: It is now possible for components to create new resources, using the makeResource() method. Furthermore, when making HTTP requests using the httpGet() or httpPost() methods, a timeout can now be specified. This is utilized by the new Failover component, which is provided with RESTx and which sequentially retries a number of URIs to receive data, using configurable timeouts.

Deployment behind proxy: RESTx can now be deployed behind a proxy front end. For example - assuming RESTx listens on port 8001 - a proxy may be configured to direct all queries for http://localhost/some_path to http://localhost:8001/some_path. This has a number of benefits: (1) the proxy front end may be used to effectively serve static content. (2) it may be used to provide SSL connectivity for clients. (3) path based access control can be implemented in the front end. To use this feature, just set the DOCUMENT_ROOT variable in $RESTX_HOME/src/python/settings.py.

Handling of form data: Parameters or input for components' service methods can now be provided by POSTing JSON or simple HTML form data. Previously, run-time parameters only could be set on the URI command line and input to a method was not interpreted at all. But now - if so requested - a component's service method may accept values for its parameters also by POSTing data in those two content types. Likewise, input in those content types is converted to proper objects of the component's implementation language.

Miscellaneous fixes and improvements: A number of smaller performance improvements, bug fixes, improved exception handling and some cleanup.