We are currently using the following conventions to represent a request
- If a
query object is passed in the JSON, a request will be created with all parameters inside the object as URL parameters. GET method will be used.
- If a
body object is passed in the JSON, a request will be created with the contents of body in the request body. POST method will be used.
A more natural and comprehensive set of conventions are:
- Wrap your request in a
request object in the root. This will keep alignment with the response representation, which will contain the request and the response.
- Inside your
request, use a method field to indicate the HTTP method to be used in the request. If no method is provided and no default method is configured, GET will be used.
- The following attributes can also be specified to further refine the request.
- A
path string for passing the path to be used in the request. If no path is provided in the request or in the configuration, / will be used as default.
- A
query object for passing a set of key-value query parameters to be used in the request
- A
headers object for passing a set of key-value headers to be used in the request
- A
body object (for POST method only) for sending a generic JSON object in the request body
- A response is represented in
response object in the root. A response can also contain headers and body. The response status is represented in a status field.
- Optionally a
context object can also be passed in the root to allow for context propagation.
- Any object or key not specified above will be simply ignored.
A domain is also required creating a request. This parameter is constant across the whole execution and must be provided in the general configuration.
Examples:
-> {"request": {"method": "GET", "path": "/api/breeds/image/random"}, "context": {"id": "some_id"}}
<- {"response": {"body": {"message": "https://images.dog.ceo/breeds/terrier-australian/n02096294_6689.jpg", "status": "success"}, "status": 200}, "request": {"method": "GET", "path": "/api/breeds/image/random"}, "context": {"id": "some_id"}}
-> {"request": {"method": "POST", "path": "/posts", "body": {"title": "foo", "body": "bar", "userId": 101}, "headers": {"Content-type": "application/json; charset=UTF-8"}}, "context": {"id": "some_id"}}
<- {"response": {"body": {"title": "foo", "body": "bar", "userId": 101, "id": 101}, "status": 200}, "request": {"method": "POST", "path": "/posts", "body": {"title": "foo", "body": "bar", "userId": 101}, "headers": {"Content-type": "application/json; charset=UTF-8"}}, "context": {"id": "some_id"}}
We are currently using the following conventions to represent a request
A more natural and comprehensive set of conventions are:
requestobject in the root. This will keep alignment with the response representation, which will contain therequestand theresponse.request, use amethodfield to indicate the HTTP method to be used in the request. If no method is provided and no default method is configured,GETwill be used.pathstring for passing the path to be used in the request. If no path is provided in the request or in the configuration,/will be used as default.queryobject for passing a set of key-value query parameters to be used in the requestheadersobject for passing a set of key-value headers to be used in the requestbodyobject (forPOSTmethod only) for sending a generic JSON object in the request bodyresponseobject in the root. Aresponsecan also containheadersandbody. The response status is represented in astatusfield.contextobject can also be passed in the root to allow for context propagation.A domain is also required creating a request. This parameter is constant across the whole execution and must be provided in the general configuration.
Examples: