Best Practices
- Coupling to DfE
- HTTPS certificates
- IP addresses
- Cross-origin resource sharing (CORS)
- Changes will affect your application
Follow best practice to make sure your application does not fail when changes are made to the production environment.
Coupling to DfE
Avoid tightly coupling your application to DfE. The systems will be dependent on one another so a change to one will affect both.
Use loose coupling - this reduces dependencies so that non-breaking changes will not affect your application.
HTTPS certificates
Use a global root CA keystore and do not pin DfE specific certificates.
Find and Use an API’s HTTPS certificates can change - this includes the leaf, intermediary and root certificates.
If you import any DfE specific certificates into your keystore or load balancer, your application may fail to connect when changes are made to the certificate.
IP addresses
IP addresses can change because we cannot supply static addresses.
To access our API platform and token generation with your application:
- you might need to configure your network
- any end users might need to configure their own network
You need to configure your network access in your proxy, not your firewall.
Cross-origin resource sharing (CORS)
The Find and Use an API service does not support CORS (opens in a new tab). It is not possible to call our APIs from client-side code within a web browser, for example using Ajax.
Changes will affect your application
A breaking change is a change to the DfE API platform that requires you to make changes to your application so it continues to work.
Breaking changes can be:
- API specific
- Platform wide (for example TLS version and cipher suite changes)
The breaking change will be published to the sandbox initially and we recommend you run your automated test pack against the sandbox on a regular basis.
See the reference guide for further detail.