API Platform Architecture
The choice of API platform is the corner stone of your digital transition roadmap. Organisations for longtime invested heavily in exposing their processes in the hope of making reusable digital assets to support their growth. In this document we explain some of the key components of API Platform architecture that we have implemented for our clients. We lay down the architecture to key components of API Gateway, Security Gateway and Service Gateway. This terminology varies across different vendors, for example MuleSoft advocates the layered architecture of Experience API, Process API and System APIs. Ultimately the goal is to follow the separation of concerns pattern by placing an grouping APIs based on their purpose.
At Xagrose we can help you in designing microservices, building microservices. If you are thinking of starting a project why not trying one of our custom tailored microservices training courses. If you are interested to know more about our services Contact Us.
The main driving force for API gateway is different characteristics of the clients connectivity to the back-end systems. A mobile app connected through a mobile network is usually slower with higher latency compared to a LAN or WAN networks and hence, the role of API gateway is to optimise the connectivity for this purpose. In some cases, the requests would be proxied through the back-end services while others would be fanned out to multiple services. It is common that through API Gateway handles the security aspects and ensures the right level of access provisioned for the underlying services.
Within the Spring-Boot MicroServices, Zuul is a natural fit for this layer. Apache Zuul is derived from Netflix MicroServices architecture and it meant to provide dynamic routing, monitoring and residency.
Security is the corner stone of enterprise architecture that a solution architect should careful craft a security architecture based on organisation needs and security concerns. However, there are common bespoke patterns employed successfully within the industry and have become de facto standards. The simple question is “who can access what”. In a technical term, authentication, authorisation. On the other hand data security is another aspect of security architecture and that should demonstrate how data is safely and securely shared with trusted parties over the net. The first part is addressed by employing Access Management solutions such as Active Directory services such as LDAP or Microsoft Active Directory. However, in an heterogeneous deployment where there are various different systems deployed, a strategic choice which is strongly recommended is employing a Single Sign On (SSO) system. The SSO sits nicely with Active Directory using Federated Identity Management system. If you require more information, please connect with us using our free consultation services.
In an API led integration, security tokens are widely used for verifying the security claims across multiple parties. JWT tokens are a good fit used with Spring-boot for this purpose.
On the data security aspect there numerous patterns, but the most important one is “Secure on Transit and secure at rest”. What does it mean?
Secure on transit means that the data should be transferred through a secure channel. A channel can be secured using SSL/TLS 1.2 protocol. In a simple term, the endpoints should support SSL/TLS protocols. On the other hand, “secure at rest” means that data should be encrypted before leaving the platform at client side and should be stored in an encrypted format before consumption or processing. Data is only decrypted at the time of processing.