Tags

codes, HTTP, IANA, IETF, RFC

When it comes to the use of micro-services and APIs. It appears pretty common for a few key response codes to be used. However, if you look at the IANA Status Code Registry of defined codes, there a number of other very useful codes that can help convey issues clearly, without compromising security.

The IANA list references the relevant IETF RFCs, but I’ve taken this a step further and obtained the relevant deep hyperlinks to the code explanations. In addition to that, I’ve also highlighted some response codes, that perhaps benefit from a closer look, or considered with caution.

Continue reading →

Tags

API, API-CS, cache-control, caching, Coherence, ehcache, forceResponse, Helidon, IETF, Oracle, proxy, Redis, RGC

We have been developing some advanced custom API policies for a client and in the process picked up on a few insights that didn’t even make into the API book. One of these policies is to provide an optimization around caching of API calls. The rest of this blog will talk about the tricks we have specifically applied to link an API Gateway to a caching mechanism and why.

Before I go into the details, I’d like to thank the Oracle product management team and particularly Glenn Mi at Oracle for their support getting through the deeper undocumented elements of the capabilities of the API Platform SDK.

Caching Options

Caching comes in may forms, and is motivated by varying reasons and not always the wanting the same behaviours. When getting into the subject of caching it is surprising how polarised people’s view points can be about which cache strategies are correct. The following diagram illustrates the diversity of caches that could appear in an end to solution solution.

Bringing together a caching technology in the Reverse Proxy model and an API Gateway makes a lot of sense. Data being provided to API consumers needs to be protected whether it comes from a cache or an active back-end system. At the same time you also want to exploit an API Gateway to provide analytics on API traffic, so any caching needs to be behind the gateway. But, if In front of an application layer then we can reduce the application workload.

When it comes to caching technology to partner with the gateway, there are a number of options available from Coherence to ehCache, memcache and Redis. We have avoided Coherence, whilst the gateway currently runs on a WebLogic server, we don’t want to need to unduly distort the performance profile and configuration of the Gateway by forcing a cache onto that server. In addition to which as Coherence is a licensed addition to WebLogic it raises difficult questions about licensing when deploying gateways (with gateways licensed based on logical groupings and API volumes but Coherence is licensed by OCPU). We also know that Oracle is moving towards having a micro-gateway which may mean we see the gateway engine moved onto something like Helidon (but this last point is my speculation).

We have elected to use Redis for several reasons –

Available as a PaaS service with several cloud providers (AWS & Azure) so no setup or management effort but can also be deployed on-premises,
Has an out of the box deployment that means cached entities can have a time to live (TTL) rather than needing to implement separate processes to expire cached values,
The ability to make it scale through clustering,
Cost

This caching model also allows us to optionally allow application development teams to push into the cache directly results. So rather than waiting on TTL the cache can be refreshed directly or even primed, rather than having to create fake requests to prime a cache.