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

Improve handling of responses #45

Open
tglman opened this issue Apr 11, 2020 · 1 comment
Open

Improve handling of responses #45

tglman opened this issue Apr 11, 2020 · 1 comment

Comments

@tglman
Copy link
Contributor

tglman commented Apr 11, 2020

Hi,
Been using this for more then a month now, I really like it and I see more features on top of this, in the specific an improved response handling with the possibility to introduce validations of the responses in a standard way not with script.

In the specific what i would like to have is a more declarative way to do the checks that i may make the script for example:

POST https://host/my/api
Content-Type: application/json

{"data":"value"}

EXPECT STATUS 200
EXPECT RESPONSE JSON({"result":"ok"})
EXPECT HEADER Content-Type:application/json

This is a basic example, it may definitely look in a different way and have even different approach to the same solution.

I would like actually to implement this myself, or collaborate to even a better solution if you like, just coming by to see if you like this approach of you prefer let dot-http go to a different path.

Regards

@bayne
Copy link
Owner

bayne commented Apr 12, 2020

dot-http was inspired by the HTTP client in IntelliJ: https://www.jetbrains.com/help/idea/http-client-in-product-code-editor.html#using-response-handler-scripts

The solution they have (which is the direction I'm leaning) is to use the scripting language to do the assertions:

> {%
    client.test("Request executed successfully", function() {
        client.assert(response.status === 200, "Response status is not 200");
    });
%}

I like the idea of the declarative approach since the goal is to keep the scripting to a minimum (smidgen of magic).

Keeping the syntax consistent is the direction I would like to go and I could see a declarative language being defined with different response handler tags, for example:

> {#
EXPECT STATUS 200
EXPECT RESPONSE JSON({"result":"ok"})
EXPECT HEADER Content-Type:application/json
#}

Note that the tags are > {# instead of > {%.

My main use-case for the response handler is to extract field values out of the response JSON. How do imagine handling that case with your declarative approach?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants