Multi Domain REST API routing for Data Mesh based Data Products
0 likes28 views
The document discusses establishing a naming convention for customer-facing APIs within a data mesh environment, focusing on the challenges of exposing various data products across domains. It presents two potential solutions: one using a fully qualified domain name with centralized routing, and another using subdomain-based routing to streamline interactions while noting trade-offs like loss of centralized control. The information is intended for guidance only and not as a commitment to deliver specific features or functionalities.
Multi Domain REST API routing for Data Mesh based Data Products
- 1. Multi-domain REST API routing Building a standard naming convention for customer facing APIs in a data mesh Johan Louwers CEA – EMEA APR-2024
- 2. The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, timing, and pricing of any features or functionality described for Oracle’s products may change and remains at the sole discretion of Oracle Corporation. Safe harbor statement Copyright © 2024, Oracle and/or its affiliates | Johan Louwers – Chief Enterprise Architect
- 3. Fair warning from the presenter Copyright © 2024, Oracle and/or its affiliates | Johan Louwers – Chief Enterprise Architect 3 Commonly problems can be solved in multiple ways, this is just an example of one of the possible routes you can take to solve this specific problem.
- 4. API request routing for data mesh data products Copyright © 2024, Oracle and/or its affiliates | Johan Louwers – Chief Enterprise Architect 4 Problem Statement: There are several data products within separate sub-domains, and the aim is to expose them through REST APIs while maintaining consistent and logical naming conventions across these diverse domains.
- 5. API request routing for data mesh data products Copyright © 2024, Oracle and/or its affiliates | Johan Louwers – Chief Enterprise Architect 5 Solution 1: Establish a Fully Qualified Domain Name (FQDN), as an example we will use api.company.com, and employ routing and proxy functionality to direct specific paths like /products, /stock, and /orders to their corresponding data product subdomains, enabling them to handle the requests Downside; a central component in the form of API routing / proxy services which results in lesser autonomy of each individual business application domain. Als introducing an additional single point of failure
- 6. API request routing for data mesh data products Copyright © 2024, Oracle and/or its affiliates | Johan Louwers – Chief Enterprise Architect 6 Solution 2: this involves implementing subdomain-based routing, where each subdomain under the main domain corresponds to a specific data product. This approach eliminates an extra layer between the consumer and provider, streamlining the interaction process. Although this approach offers advantages, it's essential to consider the trade-offs. With subdomain-based routing, centralized control mechanisms, logging, and authentication functionalities are lost with the removal of the intermediate layer.
- 7. Thank You Johan Louwers 7 Copyright © 2024, Oracle and/or its affiliates | Johan Louwers – Chief Enterprise Architect July 4th, 2023