My last post on architecture was quite some time ago. The delay has nothing to do with me being RESTful, but with the many information exchanges and discussions our Software Drives 2030 survey and this blog have raised. RESTful services as an architectural pattern appears quite frequently as a topic. Therefore I’d like to share some further thoughts on this with you.
RESTful services are a typical architectural pattern in the world wide web. They provide a robust interface to the IT world, which can be extended relatively simply and highly compatible with consumer and business applications, mobile devices and server infrastructures. The flexibility offered by RESTful services makes them suitable for the extensibility required by the connected layers. Additionally the address space of IPv6 guarantees sufficient IP addresses, even if every service in every vehicle needed to be uniquely identifiable.
The implementation of such a RESTful service on an automotive control unit is fundamentally the same as for the internet. Basically the service call in a vehicle corresponds to the call of a URL in the www. The service is identified and called by its address and delivers the same answer for every request. For a service to be considered a REST service it needs to fulfill the following requirements:
- Addressability: the service offers its resources to all clients in the net via a unique address – it’s URL.
- Different representations: the service can be addressed via different representations (XML, JSON, …), depending on the type of service request. This ensures high flexibility and ease of use.
- Access protocol and statelessness: REST does not require and specify protocol to be provided. However, most services are accessed by http. This means that the operations GET, PUT and POST are most commonly used to access and update the REST resources. Repeated invocation of the same operation shall have the same effect as performing this only once.
Good simplicity and high flexibility in use need to be complemented by effective security solutions. Turning a control unit into a server providing RESTful services could be achieved by extending the existing software of the control unit by ensuring that all internet connectivity is executed in a sandbox. The sandbox protects the control unit. This could be implemented by allowing the original software of the control unit to store data in the sandbox, while preventing the software that runs in the sandbox from accessing (neither read nor write) areas outside the sandbox. This ensures no access from the outside can read or even modify the original data of the control unit.
It is not expected that all new services in vehicles will be implemented using the RESTful pattern. However, its flexibility and simplicity allow this pattern to offer what currently are the key properties needed for development of embedded software on the connected layer: speed of technical realisation, extensibility, and compatibility with the IT world.