HyperSwitch
|
x-setup-handler
and x-request-handler
. x-setup-handler
is run during RESTBase start-up, while the x-request-handler
is executed on every incoming request, and can be made up of multiple sub-requests executed in a sequence of steps.x-setup-handler
stanza is typically used to set up storage or do any preparational requests needed on startup. And example of a setup declaration:PUT
method is used for a request. This example would initialize a testservice.test
bucket in a key_value
module.x-response-handler
, as the responses are saved in a request-global namespace.request
: a request template of the request to issue in the current blockcatch
: a conditional stanza specifying which error conditions should be ignoredreturn_if
: Modifies the behavior of return
to only return if the conditions in return_if
evaluate to true.return
: Return statement, containing a response object template. Aborts the entire handler. Unconditional if no return_if
is supplied. Only a single request within a step can have return
or return_if
set.response
: Defines a response template like return
, but does not abort the step / handler.catch
property is defined, or if it does not match, errors (incl. 4xx and 5xx responses) will abort the entire handler, and possibly also parallel requests If all parallel requests succeed, each result is registered in the global namespace. If return_if
conditions are supplied, those are then evaluated against the raw response value. Next, return
or response
statements are evaluated. These have access to all previous responses, including those in the current step. The response
template replaces the original response value with its expansion, while return
will return the same value to the client if no return_if
stanza was supplied, or if its condition evaluated to true against the original responses.hello
endpoint with the following API:request.params
object. For more information about path templates see swagger docs. For each path you define a set of request methods, GET
in our case and specify the description of the endpoint as well as request and response content type and format. All request parameters should be specified in the parameters
property, because RESTBase would automatically validate every incoming request and check whether all required params are present, have the right type and schema.operationId
and forward the request to the JavaScript handler. That's good when you need to do some complex logic to process the request, but our handler is not very complicated - it just forwards the request to the backend service. For simpler handlers there's a YAML config format that allows you to create new endpoints without any JS code.Cache-Control
header to the response.x-modules
array under the path prefix you need. For this example service the path to the module would be /hello
, it doesn't exist yet, so you would add the following code:Cache-Control
header value. Here's the code you would add to the file:npm start
and check that your API endpoint works correctly and shows up on the docs page at http://localhost:7231/en.wikipedia.org/v1/?doc