jonaslu / ain Goto Github PK

Instead of having to run something like

ain base.ain some-request.ain

it would be good to be able to specify the base in the .ain file as a block.

Then we could simply run

ain some-request.ain

I am imagining the template would look something like this

[Base]
base.ain (or potentially path to the file)

[Host]
/api/blog/create

[Method]
POST

[Body]
{
  "title": "Million dollar idea",
  "text": "A dating service. With music."
}

Let me know if you would consider this as a feature. I am happy to implement this as a feature if you dont have time.

I wanna use https://github.com/fullstorydev/grpcurl via ain!

Is it possible to support? I wanna contribute

Hi. hope you are fine. :)

Is there a way to run the same query on multiple endpoint for example:

curl -XDELETE http://elastisearch.local/index_1
curl -XDELETE http://elastisearch.local/index_2
curl -XDELETE http://elastisearch.local/index_3

btw. thank you for this awesome tool.

I gave this a try for some elasticsearch querying work but couldn't find anything that'd let me do response processing.

For simple stuff I can pipe to jq just fine, but it might be nice to be able to encode something like jq .hits.total.value into the ain file to get just that portion of the response, or indented JSON response output.

If it's there and I missed it let me know, but seems like for now pipe is the only option.

In the [Body] section, I'm passing a JSON object with these details:

{
  "email": "[email protected]",
  "password": "0x143#",
  "user_type": "tenant"
}

ain interprets # part of the password field as the start of a comment, resulting in this body instead:

{
  "email": "[email protected]",
  "password": "0x143
  "user_type": "tenant"
}

This is causing the request to fail because the resulting body is not valid JSON.

How to replicate error:

This ain file should output connection headers to stderr and print a json to stdout.

[Host]
http://localhost:3000/places

[Headers]
Content-Type: application/json

[Backend]
curl

[BackendOptions]
-sS -D /dev/stderr

But what actually happen is that stderr (the headers) are printed on stdout.

You can check this by running this line and reviewing the content of headers.txt file:

ain the_code_provided.ain 2>headers.txt

Why I consider that this should not be like this?

1. Because as user I expect to be printed to stderr
2. Because stderr could be used for logging and will allow to do this with the provided example :

ain the_code_provided.ain | jq

And don't make crash the jq parser.

Thanks in advanced!

Passing variables as environment variables is fine for configuration variables, but having used ain a bit, I feel that passing variables as arguments would be much more natural when the variable in question varies often. This applies both when scripting and on the command line.

Using a double hyphen to denote that the following arguments are variables might be a good way to do this. It would allow easy editing of parameters when calling the same endpoint a few times.

$ ain -e config.env base.ain specific_query.ain -- --id=2
push up arrow and change the id
$ ain -e config.env base.ain specific_query.ain -- --id=3

When scripting

NB: I'm using camelCase for my variables that I know change often

Before

#!/usr/bin/env bash
packageSearch=$1
#search for the package to find the id
packageId=$(searchTerm=$packageSearch ain package_service_template.ain search_package.ain | jq '.[] | .id')
#view simplified event history 
id=$packageId ain keycafe_template.ain package_events.ain | jq '.[] | {eventName, user, dateCreated, location}'

After

#!/usr/bin/env bash
packageSearch=$1
#search for the package to find the id
packageId=$(ain package_service_template.ain search_package.ain -- --searchTerm=$packageSearch | jq '.[] | .id')
#view simplified event history 
ain keycafe_template.ain package_events.ain -- --id=$packageId | jq '.[] | {eventName, user, dateCreated, location}'

That's something that Insomnia does and makes it much faster to define requests. Is it something that is on your roadmap?

Please can you send a section where you can add the parameters that are GET requests

example

[Method]
GET
[Params]
page: 3

Go releaser supports snapcraft builds, so why not do that?

The regex ends at the first ) making anything containing parenthesis fail:
E g
bash -c 'cat <(echo yo)') - will fail on unterminated escape sequence because the matched executable regex will be this:
bash -c 'cat <(echo yo