Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

TheĀ Ceptor Gateway has API Gateway funtionality functionality on top of all its existing capabilities.

...

When serving APIs, you need to create a Location (seeĀ Config - Locations for details) that has its action set to serve APIs.

Lets Let's take an example:

Go to the Gateway Configuration in the menu, and add a new location:

...

Select the environment you want to serve APIs for, choose a Rate Limiter and add any API Usage reporters you wish. You can also change the interval between remote API specification reloads (a functionality of a particular API Version where the OpenAPI specification is not stored locally, but retrieved from remote - e.g. when generated using Spring Boot or other frameworkframeworks).

Rate Limiter

A rate limiter implementation decides how rate limits are implemented for this location - it is possible to add your own custom rate limiting implementation which you can use, or you can choose one of the defaults.

If no rate limiters are setupset up, rate limiting (set up on Subscription Plans and Rate Limit Groups) will be ignored.

...

  • io.ceptor.gateway.analytics.ignite.RateLimiterIgnite
    This implementation uses an Apache Ignite Cluster to store rate limits in - the rate limits are persisted within the cluster, so this will offer you the best option at the cost of a slight performance decrease in persisting the information. This performance hit will be 1-2 milliseconds in most setups, but is still measureablemeasurable.
    If exact rate limits is a priority, you should choose this implementation.
  • io.ceptor.gateway.analytics.memory.RateLimiterMemory
    This implementation stores information in-memory - it is NOT not replicated between gateways, so each gateway within a cluster has its own information stored.
    This has virtually no performance overhead, but has the disadvantage that it is not exact - since information is stored locally for each gateway in a cluster, and since it will be lost if the process is restarted.
    But, it is the fastest implementation available so you can choose this if accuracy is not a large concern, if you have relatively short-lived limitations configured, and if performance is most important.
  • io.ceptor.gateway.analytics.sql.RateLimiterSQL
    This implementation of a Rate Limiter uses SQL/JDBC towards a shared database - rate limits are persisted in the database and shared between instances - depending on the database used, there is an overhead - e.g. in Apache Derby, the overhead is ~1 millisecond, so comparable to Apache Ignite, but offering a simpler setup.

...

Note that multiple API Usage plugins can be configured at a time, so you can store API usage Usage information e.g. both in the logs, and in elasticsearch.

...