Intelligent endpoint routing

One of the issues when developing APIs is that domain names referencing an API point vary between different environments. For example, a microservice API build in a development environment to create customer accounts is likely to have an endpoint like this:

Development - https://customer.dev.company.com/accounts

In the above URL, the customer service is part of the URL domain pointing to a computing unit dedicated to the Neptune DXP Customer microservice. The .dev. portion of the URL domain points to a namespace dedicated to development only services. Finally, the /accounts endpoint is the actual resource targeted by the API to create/read/update/delete customer accounts. The same URL will look as follows in the Test and Production environments:

Test - https://customer.tst.company.com/accounts Production - https://customer.company.com/accounts

For a production instance, the environment sub-domain, for example, .prd. is typically omitted for a user-friendly URL. When making API calls to Neptune DXP Customer Service API out of a Neptune DXP app server it will be desirable to avoid making environment-specific references for API URL that will complicate your code. Instead of conditional logic to establish which environment an app is operating in, Neptune DXP allows for the intelligent routing of API calls at design time. Depending on the operating environment you can map the target endpoint relative to the operating environment dynamically determined at runtime, for example, an API operation to create a new customer account such as this:

POST https://customer.company.com/accounts

This means, when developing, testing or staging, you always reference the production version of the API URL without worrying about environment-specific domain references.

A similar approach can be adopted for API integrations between Neptune DXP microservices and the Neptune DXP SAP connector.