You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Each Response object now requires to have a specified field body. But there are responses, where a response content doesn't make a sense. For example 301 Moved Permanently should contain a location header but no content.
User can solve this issue by simply sending "body": "". This solves the problem but it's not very user friendly to force users to send the body, if it doesn't make sense.
We can make the body optional with default value of empty string. But there's a consequence - Response doesn't have any required fields. It means that this a is valid responses field value: [{}]. This is also a valid responses field value []. The difference is, that the first one defines single response that has all default value. The Route it belongs to will still match requests and return response. The second case means there are no responses and the Route will never match any request.
I have only one idea how to solve this - if user sends "responses": [], Trickster will automatically add a default Route, meaning these two payloads are equivalent: [{}], [].
The question is, which is the lesser evil. We want to choose the less confusing solution.
Trickster now allows specifying a Route with no Responses. Such Route will never get matched but user might have a legitimate reason create it. For example he might want to first specify a Route and add Responses later. If we add a default Response and he later adds his own, the default Response remains in the list. One solution is to add only a virtual Response that will be used only where there are not other Responses defined. We can't check if they are available as the could have had Responses that ran out of uses and in that case, we don't want to start returning default response.
Proposed Solution
Make Response.body optional. Default value will be empty string ""
If Route matches a request and has no defined Responses, it will return default Response.
If Route matches a request and has some defined Responses that are valid, return one of the defined Responses.
If Route has only Responses that are not valid, it will not match any request.
The text was updated successfully, but these errors were encountered:
Problem
Each Response object now requires to have a specified field
body
. But there are responses, where a response content doesn't make a sense. For example301 Moved Permanently
should contain alocation
header but no content.User can solve this issue by simply sending
"body": ""
. This solves the problem but it's not very user friendly to force users to send the body, if it doesn't make sense.We can make the
body
optional with default value of empty string. But there's a consequence - Response doesn't have any required fields. It means that this a is validresponses
field value:[{}]
. This is also a validresponses
field value[]
. The difference is, that the first one defines single response that has all default value. The Route it belongs to will still match requests and return response. The second case means there are no responses and the Route will never match any request.I have only one idea how to solve this - if user sends
"responses": []
, Trickster will automatically add a default Route, meaning these two payloads are equivalent:[{}]
,[]
.The question is, which is the lesser evil. We want to choose the less confusing solution.
Trickster now allows specifying a Route with no Responses. Such Route will never get matched but user might have a legitimate reason create it. For example he might want to first specify a Route and add Responses later. If we add a default Response and he later adds his own, the default Response remains in the list. One solution is to add only a virtual Response that will be used only where there are not other Responses defined. We can't check if they are available as the could have had Responses that ran out of uses and in that case, we don't want to start returning default response.
Proposed Solution
Response.body
optional. Default value will be empty string""
The text was updated successfully, but these errors were encountered: