Besides the usual, numerous small improvements and fixes there are also a number of exciting major new features and capabilities:
- 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 staff to create a specialized component resource by providing the DB connection string only. Users can then use this specialized component to create their own 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.
- 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 along with 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. Overall, these improvements make the sharing of RESTx components much easier.
- Various improvements to the component API now make it possible for components to create new resources on the fly. Furthermore, when making HTTP requests using the built-in facilities of the component API, 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. With the Failover component, it is trivially easy to create RESTful web services that hide the entire timeout and fail-over logic behind a single, easy to use URI.
- 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.
- RESTx can now be deployed behind a proxy front end. This has a number of benefits, which allow RESTx to be successfully used in production environments: (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. As always with RESTx, moving from development to production setup is very simple: When going to a setup behind a proxy, just a single parameter in a settings file needs to be changed. All created resources, data integration and access components simply continue to work.
We hope that you will enjoy RESTx and benefit from its simplicity and your ability to create RESTful web services quicker and easier than ever before.
No related posts.