What is an API?
Application Programming Interface
This is the mechanism by which systems can interact with each other. Not all systems publish APIs or make them available to their customers. And not all systems expose all their functionality as APIs. In brief, there are two main types of APIs:
- Get - this is the ability to automatically get information or data out of a sytem
- Put/Push - this is the ability to automatically write information back into a system
Seamless solutions
APIs aren't essential, but they significantly improve the possibility of integration.
With a GET API it's possible to create solutions that lookup or call another system. An example of a GET call would be where a customer fills out an online social care form with their name and address. Once they press a trigger button, like 'submit' there is an API call made to CareFirst to search the CareFirst database for a name and address which match the details that the customer has provided. The API call is 'getting' the information back from the CareFirst system and returning it back to another system, such as Mendix.
With a PUT/POST API call, the information is being posted into a system. Often a fully integrated solution will combine a GET call with a PUT/POST. For example, if a customer fills out an online form with their name, address and contact information. The GET call will lookup a system to find out if they match an existing system record. If they do match then a PUT/POST call might be used to take the information provided in a Mendix form, to update the CareFirst system record with a new phone number that they have just provided. Alternatively, it might be used to create a new customer record in CareFirst if none exist in the end system.
Flexibility
Designing for an organisation.
Systems that expose APIs greatly increase the opportunities for organisations to sequence solutions. They enable information to be called, updated and shared. But they require extensive process mapping to understand the operational impact of changes. Just because a system has the ability to incorporate GET and PUT/POST calls, it doesn't mean that they can be utilised where an operational process prevents it. For example, even if a new record could be technically created automatically in CareFirst on a customer form submission, it would be inadvisable without staff manually reviewing the submission first. In this case the design would first incorporate a GET call to return the response back into another system, such as Mendix. Staff would review the content entered by the resident and the system response (for example that they are not on CareFirst). By reviewing the details submitted, they might decide that they do not need to be created as a CareFirst client. In this case, the PUT/POST call would be designed to be part of a staff-triggered button. By designing in this way, the record cannot be created or changed automatically in the system by the external customer. It can only be triggered once staff have reviewed the information and chosen to push a button.
https://youtu.be/s7wmiS2mSXY
Checking the detail
System API documentation is an essential part of procurement.
Asking suppliers if they 'have APIs' isn't sufficient. There isn't just one API for a system so understanding what APIs are available before a system is procured is essential. Some systems only allow GET calls with nothing exposed as a PUT/PUSH. This means that you can read information from a system but not automatically write anything back. This is extremely limiting and will almost certainly result in manual copy/paste processing. It's also the case that even if there are PUT/PUSH APIs available, they might not be in place for all functionality. So for example, you might be able to amend an existing record with a PUT/PUSH but not create a completely new customer record without manually entering it in the end system.
To create council-wide solutions such as MyAccount, the more systems that have a full suite of APIs, the better for staff and for customers. It will enable the getting and writing back of information (where operationally possible).