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

Add support for a json file as the request body #8

Open
daleal opened this issue Mar 20, 2021 · 4 comments
Open

Add support for a json file as the request body #8

daleal opened this issue Mar 20, 2021 · 4 comments
Assignees
Labels
feature New feature or request ongoing For issues that are being worked on

Comments

@daleal
Copy link
Owner

daleal commented Mar 20, 2021

It would be nice to be able to just specify a file name and then have zum open that file and use its contents as a request body.

@daleal daleal added the feature New feature or request label Mar 20, 2021
@sehnsucht13
Copy link

sehnsucht13 commented Mar 29, 2021

Hello!

I have started working on this issue and I have currently implemented all the logic necessary to use a file as the body of a request. The only thing I am wondering about is what should the variable containing the path to the request body be called in the zum.toml file?

Currently, I have it working with this:

[endpoints.test-post]
route = "/test-post"
method = "post"
bodyPath = "/some/path/to/request_body_file"

The bodyPath variable is used to store the (relative or absolute) path to the file. Should the variable be called something else? Maybe, we can check if the body variable contains an array/list or a string. If it contains a list then it is treated as normal and if it contains a string then that string is treated as a file path to the body file. What do you think?

I have made a pull request containing my work so far if you would like to take a look at it.

P.S: Sorry for not claiming this issue earlier. I forgot to make a comment on the Issue tracker before starting.

@daleal
Copy link
Owner Author

daleal commented Mar 29, 2021

Hi @sehnsucht13! First of all, thank you for contributing to Zum!

To be consistent with the rest of the API, I think that it might be a good idea to declare that a file will be used from the config file and then pass the file path from the zum CLI. I think that the instruction for the body to be received as a json file should be given on the same body attribute, so Zum could check if the body parameter is a string or an array to determine what it needs to receive from the CLI. For example:

[endpoints.example]
route = "/endpoint"
body = "json"

That way, you could call:

zum example ./requests/body.json

This way, we avoid letting the user define an ignored body parameter. It also leaves open the possibility to, in the future, implement other formats for that file, for example:

[endpoints.example]
route = "/endpoint"
body = "toml"

That way, you could call:

zum example ./requests/body.toml

What do you think?

@sehnsucht13
Copy link

Hi!

I like the idea of using the body variable much better than what I have right now! It really is much more consistent with the API. I will make the changes in my code to use body instead of bodyPath.

@sehnsucht13
Copy link

sehnsucht13 commented Mar 29, 2021

Hi!

I like the idea of using the body variable much better than what I have right now! It really is much more consistent with the API. I will make the changes in my code to use body instead of bodyPath.

I have updated my pull request with a new commit. Now, zum will check if the body variable is a string. If it is a string and the string is equal to "json" then zum will look for a file path provided as an argument. If the body parameter is not a string then arguments will be handled in the same way as before.

Please let me know if there are any issues. I am looking forward to any feedback.

@daleal daleal linked a pull request Mar 30, 2021 that will close this issue
@daleal daleal added the ongoing For issues that are being worked on label Mar 30, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature or request ongoing For issues that are being worked on
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants