Services API Fail Safe Features
Last updated
Last updated
This section is an extension of the information provided in the API reference documentation and describes the fail-safe setup of the API end-points of Fredhopper Services and provides a guideline for the integration of these APIs.
The Services API accepts requests to supply or retrieve data and trigger the data processing. Although we support both the FTP and REST protocols to interface with the Services API, we strongly recommend using REST.
The diagram below depicts the overview of the infrastructure setup and indicates the fail-safe components:
By front-end we mean the complete set of components in the web application on the customer's side involved with the integration of the Services API. One could think of the application back end servers and the underlying infrastructure, proxies and other network appliances etc.
The front-end web application connects to the Services API endpoint via the Internet.
We register the DNS names for the API end-points with a 3rd party DNS service provider. To ensure high availability, each DNS record for the Services API endpoint contains a set of public IP addresses of our Data API servers and adheres to the Round-Robin DNS principle. In short, this means that every time the DNS name gets resolved into an IP address that is different from the previous time. In order to minimise the chance of issues related to DNS caching, we set the TTL to 30 seconds. Your Technical Consultant can provide you with a full list of the IP addresses in our range so that you can ensure that these are whitelisted on your-side, if this is required.
The hostname alone does not identify any specific service instance. Instead, the service instance is referenced in the path, e.g. https://my.<region>.fredhopperservices.com/<service>:<instance>
Each of the Data API servers (or nodes) fulfil the following functions:
Authentication Each request gets authenticated based on the supplied account credentials
Processing Once authorised, the request gets processed. Depending on the type of the request, it might be either handled directly by the Data API node, or by other internal components.
Storage The data supplied via the Services API gets stored for a short period of time alongside the information regarding the trigger processing etc.
All Data API nodes have identical configuration and functionality, they also share the same underlying storage and processing clusters.
The front-end prepares the data export, compresses it, calculates the md5 checksum and sends it to the Services API endpoint.
The Services API endpoint DNS name gets resolved. The DNS authority answers with the external IP of one of the Data API nodes.
The front-end sends the data to the IP address, indicating the service instance in the path and supplying the account credentials.
The Data API node processes the request, verifies and stores the data and assigns it a data ID, which it sends back as the response.
Make sure the DNS record is resolved each time before a request is sent and only send 1 request to 1 IP at a time.
Make sure the TTL advertised with the DNS record (30 seconds) is respected.
For a given service instance, send the requests sequentially, awaiting the response each time. For example, if the data uploading process is still running, sending a trigger would result in a failure.