API constructor (beta)
Since the 2405 release, using Aidbox in FHIRSchema mode is recommended, which is incompatible with zen or Entity/Attribute options.
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.
Common API Constructor use cases
Usage examples:
Sample API used in this documentation page example.
Example setup
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.
API constructor definitions
Entrypoint
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.
Example
Services
A service contains engine
and its configuration.
Available engines:
aidbox/http
- Describes http service, contains set ofapis
. Each api must be tagged withaidbox.rest/api
.aidbox/seed
- Creates provided fixtures on start. Described here.
Example
aidbox.rest/api
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
.
Example
aidbox.rest/op
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
Example
Available aidbox.rest/op-engines
aidbox.rest/op-engines
Miscellaneous
aidbox.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.
Regular FHIR API
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
ACL FHIR API
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:
Gateway
We provide Gateway feature to make Aidbox a proxy server for your backend application, so you can:
maintain a single entry point for your application
extend the default Aidbox APIs to include your own business logic
secure access control to your service
Example
As an example bellow we create CRUD endpoint that explains to Aidbox where is your server located and what endpoints we have to redirect
map-to-fhir-bundle
ingestion.core/map-to-fhir-bundle
- expects :format
("fhir" or "aidbox") and :mapping
in the definition. Returns result of applying lisp/mapping in to the provided data structure and persisting it as Bundle.
The result of the example below will be an POST/ingestion/map-to-fhir
endpoint accepting the data structure on which the mapping will be applied as the body of the request.
Example
Middlewares
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.
Example
List of available aidbox.rest/middleware-engine
aidbox.rest/middleware-engine
aidbox.rest.v1/match-middleware
- checks if a request satisfies to some pattern. Similar to theAccessPolicy
matcho
engineaidbox.rest.v1/params-middleware
- adds request query-string parameters taking data from the request contextaidbox.rest.v1/transform-middleware
- transforms incoming request taking data from the request contextaidbox.rest.middlewares/transform-request-data
- the same astransform-middleware
but provides more complex functionality
Project with API Constructor example
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.
Last updated