Diesel has API Gateway capabilities: you can quickly define routes and coreograph microservices and expose them as higher-level microservices, control traffic, get reports etc.
There are several entry points for the API Gateway:
/diesel/rest
- classic REST path mapping/diesel/mock
- classic REST preferring mocks/diesel/react
- direct message triggerThe entry points of the form /diesel/react/<message>
are wired directly to respective messages, for instance:
The arguments are passed as query parameters. Any rules matching the message and arguments are executed and the final result returned.
This is a more classic path mapping for REST.
An example rule (the message name for these is always diesel.rest
):
$when diesel.rest (path ~path "/diesel/echoJson")
=> (payload = {
status : "echoJson",
body : payload,
verb : verb,
headers : dieselHeaders
})
When using the mock entry point, the mocks are preferred (so $mock
instead of $when
).
You can parse the path automatically into segments, using several ways:
$when diesel.rest(path ~= "/myActualServer/create/(?<user>.+)")
=> myMailServer.create (user)
Will match this call: /diesel/mock/myActualServer/create/John@ and also parse and populate the user
variable in context, from the respective path segment.
Other ways to match the same would be named segment variables:
$when diesel.rest(path ~= "/using/colon/:user/showme")
The default visibility is set in the Reactor Configuration, using the property diesel.visibility
. It can take the values member
or public
by default being public
:
diesel.visibility=member
When set to memeber
it only allows API calls to authenticated users, so one of a few authentication mechanisms must be used (HTTP Basic or cookie or X-Api-Key):
X-Api-Key
is another supported mechanism. Each user has a random secret key assigned and when this is passed in via a HTTP header called X-Api-Key
the respective user is authenticatedWhen using say member
you can mark specific messages as public
and it will allow them to be accessed without authentication, such as:
$msg <public> some.message(a,b,c)
$when <public> diesel.rest(path ~= "/myActualServer/create/(?<user>.+)")
...
You can use OAUTH and integrate to an OAUTH server, see Using OAUTH++
Rate limiting for the API calls can be done in several ways.
In application.conf
you can change the size of the various thread pools and that would provide a level of resource limitations.
Also there, in the diesel
group, there are global static HTTP rate limits that you can enable:
diesel {
staticRateLimiting = true
staticRateLimitAll = false
staticRateLimit = 80
}
These mean:
staticRateLimiting
- this is a big on/off switch for rate limiting. If false, no rate limiting takes place. If ON, the global and group rate limiting configuration appliesstaticRateLimitAll
- rate limiting all calls, not just API callsstaticRateLimit
- the global rate limit, across all groups and global callsYou can define a rate limiting group say group1
and then configure rate limiting for this group, based on path or header (for REST API flows), with these messages:
diesel.apigw.limit.path
diesel.apigw.limit.header
For instance:
$send diesel.apigw.limit.path (
group="elkpt",
regex="/diesel/rest/.*/elkpt/.*",
limit=10)
Current status is reported in the /admin/status
call, here's an example with only the relevant metrics:
{
"global": {
"maxServingApiRequests":8,
"servedPages":0,
"served":3510,
"servedApiRequests":3490,
"maxDieselThreads":"100",
"serving":1,
"limitedRequests":0,
"maxServing":8,
"maxDefaultThreads":"100",
"servingApiRequests":0
},
"rateLimits": {
"elkpt": {
"maxServed":3,
"limited":0,
"served":1529,
"serving":0,
"limit":80
}
}
}
You need to log in to post a comment!