Skip to content
New issue

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

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

Already on GitHub? # 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?

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

No branches or pull requests

2 participants