Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow responses with empty body #10

Open
JakubTesarek opened this issue Mar 24, 2021 · 0 comments
Open

Allow responses with empty body #10

JakubTesarek opened this issue Mar 24, 2021 · 0 comments
Labels
enhancement New feature or request

Comments

@JakubTesarek
Copy link
Collaborator

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 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.
@JakubTesarek JakubTesarek added the enhancement New feature or request label Mar 24, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant