API constructor (beta)
Last updated
Was this helpful?
Last updated
Was this helpful?
Using Aidbox API constructor you can:
define API, endpoints, handlers, and URL params schema
specify your own middlewares (e.g. Smart on FHIR authorization middleware)
The API constructor is in beta now. Please contact us if you have questions or need help.
API constructor requires knowledge of zen language.
Sample API used in this documentation page example.
Use Run Aidbox locally to start Aidbox, here is configured API constructor example. Add these environment variables:
Once Aidbox is running, open Profiles
tab in the Aidbox UI. If everything is configured properly, page should contain namespace with AIDBOX_ZEN_ENTRYPOINT
symbol which is mybox/box
in this example. View of the symbol should show loaded routes.
Here's a notebook with the example API demo usage :
You can import it into the example and run test REST requests.
Define an Aidbox server definition with AIDBOX_ZEN_ENTRYPOINT
env, the value must be a namespace/symbol
, e.g.:
The namespace with entrypoint symbol must be loaded: file containing namespace mentioned in AIDBOX_ZEN_PATHS
and imported or specified directly inAIDBOX_ZEN_ENTRYPOINT
env.
More info on loading namespace
Entrypoint symbol must be tagged with aidbox/system
tag. aidbox/system
describes a set of services to start and configurations.
A service contains engine
and its configuration.
aidbox/http
- Describes http service, contains set of apis
. Each api must be tagged with aidbox.rest/api
.
aidbox/seed
- Creates provided fixtures on start. Described here.
aidbox.rest/api
An api
describes routing, route can contain operations, subroutes and other apis. Operations must be tagged with aidbox.rest/op
.
:middlewares
can be added to an api
.
aidbox.rest/op
An op
describes REST operation. :engine
specifies what operation handler should be used for this operation. Each engine can accept own parameters
aidbox.rest/op-engine
saidbox.rest.v1/aidbox-action
- Expects :action
, passes request to existing Aidbox action. You can see list of available operations with this request:
GET /Operation?_elements=action&_result=array&_count=1000
aidbox.rest.v1/echo
- expects :response
in the definition, returns the response.
Expect target resource type as :resource
and :format
(fhir
or aidbox
)
aidbox.rest.v1/search
aidbox.rest.v1/create
aidbox.rest.v1/read
aidbox.rest.v1/update
aidbox.rest.v1/delete
aidbox.rest.v1/patch
aidbox.rest.v1/transaction
aidbox.rest.acl/search
aidbox.rest.acl/create
aidbox.rest.acl/read
aidbox.rest.acl/update
aidbox.rest.acl/delete
See full description and usage examples:
Middlewares can change incoming request before executing op
. Middlewares are applied to aidbox.rest/api
which contains operations or other apis. On request Aidbox routing determines what op
should be executed. Before executing the op
Aidbox collects all middlewares applied to the apis containing the op. Then collected middlewares are applied in sequence to the request.
A middleware should be defined with specified :engine
. The :engine
determines what the middleware will do. Depending on the chosen :engine
middleware can accept different parameters.
aidbox.rest/middleware-engine
aidbox.rest.v1/match-middleware
- checks if a request satisfies to some pattern. Similar to the AccessPolicy
matcho
engine
aidbox.rest.v1/params-middleware
- adds request query-string parameters taking data from the request context
aidbox.rest.v1/transform-middleware
- transforms incoming request taking data from the request context
aidbox.rest.middlewares/transform-request-data
- the same as transform-middleware
but provides more complex functionality
Aidbox configuration with search and read on Observation
resource available at GET /access/Observation
and GET /access/Observation/<id>
. Defined endpoints also contain a middleware injecting patient
search parameter to ensure that user can only search for Observations for a specific patient.