Activiti and the REST API
Congrats to the Activiti team for releasing 5.13, which includes a new REST-API. They redesigned the REST API from scratch, which I think was the right move – thinking about it as a whole instead of separate, independently designed parts:
- The old API doesn’t cover all features offered by the Java API. The new version covers 99% of all methods in the API services (RuntimeService, RepositoryService, HistoryService, …), which opens up the full potential of the engine through REST. This allows other programing languages to benefit from the power of the Activiti engine.
- As requirements and use cases came along, the old API grew and evolved. Because of the use-case driven additions, there wasn’t really a common approach followed when adding new REST-calls. This resulted in differences in naming and handling between resources. The new API has introduced a uniform approach.
- The new API applies the REST-principles more strictly (resource naming, appropriate HTTP-verbs used for resource actions, use of URL’s in responses referencing other resources, using the right HTTP-response codes).
Of course, what we like about it most is how it enables alternate UIs and App embedding possibilities that a clean REST-API enables. The Activiti team has also done a good job of making sure that you can embed the API in an existing application:
It’s also possible to include the REST-API in your existing application (which may already have an Activiti-engine in it). We tried to make the REST-module (and the other modules as well, by the way) as easy to embed as possible. Just add the activiti-rest.jar as a dependency with all of it’s transitive dependencies and configure the Activiti Restlet Application. If you app runs in a web-container, Restlet is configured as a single servlet. When your application is not in a servlet-environment, you can run a standalone Restlet server to expose the REST-API for your engine.