Given the hype around the imminent Star Wars film release, we took the opportunity to combine business with pleasure when writing our recent article on consistency between APIs. In the process we began looking at the Star Wars universe and realised that Star Wars is full of “APIs”, just somewhat less conventional than those we meet in our everyday lives.
Apiway, with their years of experience as an API Design Authority in investment banking, decided to review the “APIs” we found in the original Star Wars movies in the same manner we would review API designs presented to us today.
This series of articles aims to take a light-hearted trip through the API universe…
The first API is the RPC style communication between C3P0 and R2D2 – we have presumed that it is representative of all inter-droid communication. It is interesting that the designers have decided to dismiss use of the electromagnetic spectrum (i.e. wireless networking) in favour of an audio-based protocol. Although within the Star Wars universe audible communication is generally the norm (apart from with the Jedi who apparently can also use a ‘force’ based narrow and broadcast protocol), so we will accept it as utilising an established standard.
If we were to transcribe the protocol headers of R2D2 they might look a bit like:
- Attempt to standardise on a content-type suitable for all machine interfaces.
- Investigate payload translation capabilities of available API Gateways.
- Look to simplify the language used in APIs to reduce ambiguity.
As R2D2 attempts to leave the stricken Blockade runner star ship, C3PO mentions that R2 is not allowed into the escape pods.
It is good to see that the ship designers have bothered to implement access security (possibly RBAC), however R2 promptly interfaces with the access control panel and the door to the pod opens. In this instance we assume that they utilise an established standard such as OAuth, therefore we draw the conclusion that R2 has an JWT access token granting him access. We are not sure what view the security department would take with the possible interception of, or distribution of long-lived user access tokens to system processes.
- Clarify security standards around the storage of user access tokens by system processes.
- Consider using some additional northbound security mechanisms such as client certificates (Two-Way TLS) to ensure access credentials are tied to a consumer.
- Ensure all communication of security credentials are over TLS channels.
Aside from Protocol, C3PO has been programmed for over thirty secondary functions.
We do tend to advise against APIs with more than one, single responsibility. The choice of which API to use should be obvious to consumers and this has failed in the case of C3PO as Uncle Owen isn’t immediately aware that C3PO can program moisture evaporators and speak Bocce.
- Review functionality offered by C3PO and split into multiple APIs aligned to a business function.
- Review tagging of the API in the API catalogue to ensure the functionality offered by the API is clearly identifiable.
Whilst being cleaned by Luke, R2D2 displays a hologrammatic video clip. This is quickly dismissed as ‘old data’ by the droids.
From a pure implementation perspective it is interesting that sticking a screwdriver into the inner workings of a droid can trigger a release of data. But this isn’t a true API as it isn’t machine to machine communication (we are only including it because it is critical to the story).
Although this is often considered an implementation detail (logical deletion of data), we suggest that a ‘status’ flag is delivered as metadata with the content, so any consumer can easily determine the current validity of the payload. A consumer having to separately query the validity of data will add additional latency into any process.
R2D2 gets the opportunity to connect to the Imperial network – with Ben Kenobi telling him “Plug In. He should be able to interpret the entire Imperial computer network”.
Use of API Gateway
We appreciate that the Imperial network is seemingly accessed via an API Gateway with a developer portal of some description, allowing discovery of services available. This ‘all in’ approach to building an API economy is to be applauded as it can be a great way of driving unintended value for consumers such as allowing the development of escape-route apps or identifying tractor beam power supply locations.
- Ensure all APIs are available via the API Gateway and listed within the Developer Portal.
- Measure consistency of API Design across API estate.
We need to highlight our concern of the apparent lack of security once inside the firewall. It seems that unlike the builders of the Rebel’s Blockade runner, the imperial API designers have not consistently utilised OAuth or similar security framework. R2D2 can connect and interrogate the network without difficulty – making assumptions that there will be no bad actors within the physical perimeters of your organisation can lead to significant damage being done.
Despite R2’s apparent ease of access to the Imperial network, C3P0 mentions that “All other information on that level is restricted” – so RBAC is in use for some APIs. R2 has access to core security (prisoner) and infrastructure (tractor beam/garbage masher) services, but others are restricted.
A review of all the Imperial Open API specifications, to ensure consistency in their application of security, particularly given they are already likely to have security capability available from the API Gateway. Additionally, the partitioning of API functionality by ‘level’ of the space station feels counter-intuitive and we would advise reviewing the use cases associated with partitioning of services.
No, Shut them all down! Hurry!
R2 seems to want to shut down a specific garbage masher on the detention level, one must assume that this is due to a RESTful resource access. In order to shut them all down he (it?) must iterate through all the garbage mashers in turn and deactivate them. We don’t have any indication of how many garbage mashers the detention level of the death star has, but the hatch into the compartment is numbered 3263827.
Discuss the use cases related to the garbage masher API with the designers and consumers. It may well be that exceptional cases requiring all mashers to be shut down are so few and far between that it is not an effective use of resources to implement. Additionally, it is strongly advised not to mix RESTful and RPC style in a single API so an effective RESTful manner of representing batching against resources would need to be agreed upon.
The Imperials use integer resource IDs on their pressure maintenance hatches, which easily allows R2 to open the right one. The API may be RESTful or RPC-style but the functionality should still be easy to identify and utilise.
We have to ‘thank the maker’ that some thought has been given to usability of this API and hopefully this has been applied throughout the Imperial network.
Assuming the API for manipulating the Pressure maintenance hatches has an integration with the garbage masher API (to prevent the hatch opening during a mash operation) we are happy with the design of this API.
There is a lot wrong with APIs in the Star Wars – A new hope. We wouldn’t have let most of them get to production. We will review the ones we find in the Empire strikes back in another article and hope to see some better design applied therein.