VETRO Pattern for API Gateways

VETRO is a popular acronym that summarizes most of the benefits offered by middleware solutions like ESBs and API gateways. VETRO highlights the key functions of API gateways, though gateways can also support a number of microservices patterns like Microservice.io or EIP patterns.

VETRO stands for:

• Validation – As the name suggests, it means validating request message as per any agreed conventions or contracts. Several frameworks or tools are used to validate the message before it reaches the backend services. Available frameworks are:
• Bean validation (JSR 380) for doing validations in plain Java.
• JSON Schemas are being actively developed, but XML Schemas for XML messages are fully developed if XML is an option.
• Schematrons for XML are not relevant in JSON world
• Authentication and Authorization are best done in OAuth 2.0/OpenID Connect using JWTs
• Frameworks like SAML and WS-Policy do exist, however they are going irrelevant in REST/JSON era.
• Enrich – As an active intermediary, a gateway enriches the messages in message flows before passing it to backend services
• Smart endpoints and dumb pipes is one of the popular design pattern which makes a strong case to keep Gateways as dumb as possible. Service composition or aggregation is a slippery slope as it opens up for developers to add complex logic (could be business logic) in Gateways. 
• Netflix like companies took U-turn on “smart endpoints and dump pipes” pattern and doing service aggregation in Gateway for improving scalability, performance to cater to a large variety of devices.
• Enriching the messages between front and backend systems often involves validating security and adding relevant user context and tailoring messages for receiving party, but developers must use caution and not add any business logic in Gateway. 
• Transform
• Transformation of messages from backend systems to API friendly data representations like JSON or XML
• It is common practice to transform the backend service data and filter the data fields that are interested by the consumer. Netflix sets a very good example towards this practice. 
• Route & Operate 
• Routing the calls to respective backend services based on request URL, query parameters and Operating the service i.e., actual invocation of the service over its real endpoint.
• Often, service traffic is routed through many intermediaries like reverse proxies, web servers, load balancers, etc… It gets very annoying to isolate the one who ate your headers. So, use caution when using transport headers for routing the consumers. 

Conclusion

1. SOAP services are deprecated in the industry in favor of lightweight replacements like REST services

2. XML representation of data is being deprecated in favor of lightweight JSON representation. This also due to the amazing return of Javascript and its widespread adoption in modern applications.

3. Resource-based services (RESTful APIs) over coarse-grained business functions as services

4. Models in MVC are shifting to client-side instead of server-side MVC, again due to advancements in browsers and JavaScript engines.

Enterprise integration came long way and morphed into many shapes: EAI to SOA, SOA to API, API to Microservices, and now Serverless. We just need to wait and see where serverless architectures will take us!