-
Notifications
You must be signed in to change notification settings - Fork 11
Managing Stubs Using the REST API
The gRPC mock server is capable of returning any success or error response. Ir order for it to know what response to send for a specific request it is necessary to create stubs and it is done through its REST API. When the gRPC server starts, by default it is listening on two different ports: 1068 and 10010. Port 1068 is the REST API endpoint that we will use to manage the stubs. See Starting the Mock Server for information on how to change the default ports.
The API consists of two endpoints:
The stubs stored in the server only live while the server is running.
Endpoint: /stubs
Exposes a CRUD interface for stub management.
Method: POST
Body: Stub
Method: GET
method OPTIONAL
If provided returns only the stubs added for the gRPC method. Otherwise returns all stubs.
Method: PUT
Body: Stub
Method: DELETE
Deletes all stubs.
Optionally a method name can be provided as a query parameter, in that case all stubs stored for the provided method will be deleted.
Optionally a stub can be provided in the body, in that case only that stub will be deleted.
Body: Stub OPTIONAL
method OPTIONAL
If provided only the stubs added for the provided method will be deleted.
Endpoint: examples
Returns auto-generated stub examples for all supported methods in the server.
Method: GET
A stub has this basic structure:
{
"fullMethod": "/carvalhorr.greeter.Greeter/SayHello",
"request": {
"match": "exact | partial",
"content": {},
"metadata": {}
},
"response": {
"type": "success | error",
"content": {},
"error": {
"code": 0,
"message": "",
"details": {}
}
}
}The fun gRPC method name.
Tip: The method names supported by the server are logged when the server starts up.
The request definition to be matched against incoming gRPC requests.
Determine how the stub will be matched against an incoming gRPC request. If it matches then the response is returned for the incoming request.
Possible values: exact or partial
If the stub defines the exact match mode then all the fields in an incoming request must match all the fields defined in the stub`s stub.request.content.
If the stub defines the partial match mode then only the fields defined in stub.request.content must match the fields in an incoming request in order for the response to be returned.
The JSON definition of the request to be matched against incoming requests. Note that it is the proto JSON representation of the message instead of the regular JSON representation.
Optionally, metadata can be used to determine if an incoming request matches a stub. If provided, the fields added to the metadata must match the metadata in an incoming request for a response to be returned.
Each metadata field is of type string. To provide multiple values, separate them by a comma.
The definition of the response to return in case an incoming request matches the stub.
Defines the type of response to return: success or error.
The response content to return in case the field stub.response.type is success. This is the JSON that will be unmarshaled to the response type defined in the API. Like stub.request.content, this is the proto JSON instead of the regular JSON.
The error to be returned in case the request matches the stub and the field stub.response.type is error. Errors are described by status.Status.
The error code. See Code. In addition to the defined error codes, any unsigned int 32 can be used.
The error message.
See Advanced error mocking to learn how to add details to the error response.