Metadata-Version: 2.4
Name: dothttp-req
Version: 0.0.44a37
Summary: Dothttp is Simple http client for testing and development
License: MIT
License-File: LICENSE.txt
Author: Prasanth
Author-email: kesavarapu.siva@gmail.com
Requires-Python: >=3.12,<3.15
Classifier: License :: OSI Approved :: MIT License
Classifier: Operating System :: OS Independent
Classifier: Programming Language :: Python :: 3
Classifier: Programming Language :: Python :: 3.12
Classifier: Programming Language :: Python :: 3.13
Classifier: Programming Language :: Python :: 3.14
Requires-Dist: cryptography (==50.0.1)
Requires-Dist: faker (==40.21.0)
Requires-Dist: idna (==3.18)
Requires-Dist: jsonschema (==4.26.0)
Requires-Dist: jstyleson (==0.0.2)
Requires-Dist: msal (==1.38.0)
Requires-Dist: parsys-requests-unixsocket (==0.3.2)
Requires-Dist: pyyaml (==6.0.3)
Requires-Dist: requests (==2.34.2)
Requires-Dist: requests-aws4auth (==1.3.2)
Requires-Dist: requests-hawk (==1.2.1)
Requires-Dist: requests-ntlm (==1.3.0)
Requires-Dist: requests-pkcs12 (==1.27)
Requires-Dist: restrictedpython (==8.5)
Requires-Dist: textx (==4.2.3)
Requires-Dist: toml (==0.10.2)
Requires-Dist: truststore (==0.10.4)
Requires-Dist: urllib3 (==2.7.0)
Requires-Dist: xmltodict (>=1.0.2,<2.0.0)
Project-URL: Bug Tracker, https://github.com/cedric05/dothttp
Description-Content-Type: text/markdown

# Inspiration

With the rise in usage of microservices, Making http requests is essential job of most devs. For these, there are multiple options like curl, insomnia postman. My Ideal choice is to use curl but problems with it is, having no history and no easy way to save and rerun. Postman solves that problem, but once user logs in(earlier it used to be optional, now its mandatory), it stores all request metadata(body/headers/urls/credentails) to their servers although it helps solve using it across multiple devices, backup but it could be potential security loop hole if they can access it. (now a days, postman desktop is super slow also).

This project aims to solve save&reuse requests, maintaining history and no sync in proprietery servers (although you can achive sync via commiting http files into git).

## GOAL

dothttp will provide simple, cleaner architecture for making http requests. It uses xtext (eclipse developed dsl) to build a custom dsl.


### Documentation

More information or docs can be cound at https://docs.dothttp.dev


---
Go through this example for better understanding. for babysteps click [here](#first-dothttprequest-and-more)
```http
# users.http

#!/usr/bin/env /home/prasanth/cedric05/dothttp/dist/dothttp-cli

var name=adam; // this is how variable is created;
var username='username'; 
var password='password';

# this is comment

// this is also a comment

/*
   this is multi line
   comment
*/

# http file can have multiple requests, name tag/annotation is used to identify
@name("fetch 100 users, skip first 50")

# makes are get request, with url `https://req.dothttp.dev/user`
GET https://req.dothttp.dev/user

# below is an header example
"Authorization": "Basic dXNlcm5hbWU6cGFzc3dvcmQ="

# below is how you set url params '?' --> signifies url quary param
? ("fetch", "100") #
? ("skip", "50")
? projection, name
? projection, org
? projection, location




# makes are post request, with url `https://req.dothttp.dev/user`
POST https://req.dothttp.dev/user

basicauth('username', 'password')
/*
   below defines payload for the post request.
   json --> signifies payload is json data
*/
json({
    "name": "{{name}}", # name is templated, if spcified via env or property, it will be replaced
    "org": "dothttp",
    "location": "Hyderabad",
    # "interests": ["exploring", "listening to music"],
})



# makes put request, with url `https://req.dothttp.dev/user/1`
PUT https://req.dothttp.dev/post

# define headers in .dothttp.json with env
basicauth("{{username}}, "{{password}}")

# posts with urlencoded
urlencoded({
    "name": "Adam A",
    "org": "dothttp",
    "location": "Hyderabad",
    "interests": ["exploring", "listening to music"],
})

// or use below one
// data('name=Adam+A&org=dothttp&location=Hyderabad&interests=%5B%27exploring%27%2C+%27listening+to+music%27%5D')
```

## KICKSTART

### From pypi

```shell
pip install dothttp-req==0.0.10
```

### From source

```shell
git clone git@github.com:cedric05/dothttp.git
cd dothttp

python3 -m pip install pipenv
pipenv install
```

### python3.9

```shell
python3 -m dothttp examples/dothttpazure.http
```

### docker

```shell
docker build -t dothttp .
docker run -it --rm dothttp
```

### whalebrew

```shell
docker run -it --rm dothttp
```

## Features

1. easy and cleaner http syntax
1. variable substitution with property file
1. generates curl from http for easy sharing

```shell
docker build -t dothttp .
whalebrew install dothttp
dothttp examples/dothttpazure.http
```

## First DotHttpRequest and more

```get.http
GET "http://localhost:8000/get"
```

`dothttp get.http`  or `python -m dothttp get.http`

## Run

`dothttp simple.http`

prints

```json
{
  "args": {},
  "headers": {
    "Accept-Encoding": "identity",
    "Host": "httpbin.org",
    "User-Agent": "python-urllib3/1.26.3",
    "X-Amzn-Trace-Id": "Root=1-6022266a-20fb552e530ba3d90c75be6d"
  },
  "origin": "117.216.243.24",
  "url": "http://localhost:8000/get"
}
```

### POST request

```post.http
POST "http://localhost:8000/post"
```

```json
{
  "args": {},
  "data": "",
  "files": {},
  "form": {},
  "headers": {
    "Accept-Encoding": "identity",
    "Content-Length": "0",
    "Host": "httpbin.org",
    "User-Agent": "python-urllib3/1.26.3",
    "X-Amzn-Trace-Id": "Root=1-602228fa-3c3ed5213b6d8c2d2a223148"
  },
  "json": null,
  "origin": "117.216.243.24",
  "url": "http://localhost:8000/post"
}
```

similarly, other methods`GET, POST, OPTIONS, DELETE, CONNECT, PUT, HEAD, TRACE` support is available.

### Query

query params can be added to request by specifying
` query ( "key", "value")`
` ?  "key", "value"`
` ? "key": "value"`
` ? "key"= "value"`
all four are accepted. going with `query("hi", "hi2)` is more readable. `?"key"= "value"` is more concise

### Payload

user can specify payload by mentioning below four forms (for various scenarios).

- `data("ram")`

  user can also mention its `content-type` with
  `data("ram", "text/plain")`
- `urlencoded({"key": "value"})` for form input.
- `json({"key": "value"})` for json payload.
- `fileinput("path/to/file", "type")` uploads file as payload (type is optional).
- `files(("photo", "path/to/file/photo.jpg", "image/jpeg"),
  ("photo details", '{"name":"prasanth"}', "application/json")   
  )`

  for multipart upload
  **dothttp** will figure out content type by going through file/data, when type is not mentioned.

### Comments

**dothttp** will use `#` for commenting entire line.

1. `//` line comment. follows java, javascript
2. `#` line comment. follows python's comment style
3. `/*
   */` multi line comment. follows java/javascript style

### Templating

```.http
POST 'http://localhost:8000/post'
? ("{{key}}", "{{value}}")
data('{"{{key}}" :"{{value}}"}', 'application/json')
```

- specify variable values through property file ([sample.json](./examples/.dothttp.json)).
    - user can define environments and can activate multiple environments at a time
    - **dothttp** by default will read variables from `"*"` section
    - for example
      `dothttp --property-file path/to/file.json --env ram chandra`

      will activate `*` section properties, `ram` section properties and `chandra` section properties
      `dothttp --env ram chandra`
      will activate `*` section properties, `ram` section properties and `chandra` section properties
      from `.dothttp.json` in httpfile name space
- through command line
  `dothttp --property key=ram value=ranga`
  will replace `{{ram}}` to `ranga` from the file
- through file itself. (will be helpful for default properties)

```
POST 'https://{{host=httpbin.org}}/post'
```

### Headers

User can define headers in below three formats

1. `header('content-type', 'application/json')` readable
2. `'content-type': 'application/json'` concise
3. property file `headers` section from property-file can also be used. in most scenarios, headers section will be
   common for a host. having them in property file would ease them.

### Authentication

#### BasicAuth
`basicauth('username','password')'` --> will compute add respective headers.

#### DigestAuth
`digestauth('username','password')'` --> will compute add respective headers.

#### NtlmAuth
`ntlmauth('username','password')'` --> will compute add respective headers.

### Property file

```json
{
  "*": {
    "host": "httpbin.org"
  },
  "headers": {
    "content-type": "plain/text"
  },
  "preprod": {
    "host": "preprod.httpbin.org"
  }
}
```

#### Special sections in property file

1. `*` section in property file will be activated once user specifies property file if user didn't specifiy file
   and `.dothttp.json` exists, it will be activated
2. `headers` once a property file is activated. headers from property file will be added to request by default without
   user having to specify in `.http` file

#### Formatter (experimental phase)

**dothttp** can format a http file using below command
`dothttp -fmt examples/dothttpazure.http --experimental`
or
`dothttp --format examples/dothttpazure.http --experimental`

to print to command line

`dothttp --format examples/dothttpazure.http --experimental --stdout`

### Editor support

syntax highlighting for visual studio code is supported
via [dothttp-code](https://marketplace.visualstudio.com/items?itemName=ShivaPrasanth.dothttp-code)

### Command line options

```
usage: dothttp [-h] [--curl] [--property-file PROPERTY_FILE] [--no-cookie]
               [--env ENV [ENV ...]] [--debug] [--info] [--format]
               [--experimental] [--stdout]
               [--property PROPERTY [PROPERTY ...]] [--target TARGET]
               [file]

http requests for humans

options:
  -h, --help            show this help message and exit

general:
  --curl                generates curl script
  --no-cookie, -nc      cookie storage is disabled
  --debug, -d           debug will enable logs and exceptions
  --info, -i            more information
  file                  http file. use `-` or omit to read http content from
                        stdin
  --target, -t TARGET   targets a particular http definition

property:
  --property-file, -p PROPERTY_FILE
                        property file
  --env, -e ENV [ENV ...]
                        environment to select in property file. properties
                        will be enabled on FIFO
  --experimental, --b   enable experimental
  --property PROPERTY [PROPERTY ...]
                        list of property's

format:
  --format, -fmt        format http file
  --stdout              print to commandline
```

checkout [examples]('./examples/dothttpazure.http')

-----------

## Using dothttp with AI agents / coding assistants

**dothttp** is stdin/stdout friendly, so an AI agent (Claude Code, Cursor, a
custom LLM tool, a CI script, etc.) can fire a request without ever writing a
`.http` file to disk or leaving temp files behind.

Pipe the `.http` content on stdin using `-` as the file argument (or just
omit the file argument altogether):

```shell
echo 'GET "https://httpbin.org/get"' | dothttp -
# or, equivalently
echo 'GET "https://httpbin.org/get"' | dothttp
```

The response body is written to stdout, exactly like the file-based flow —
no extra banners or separators clutter the output unless a test script
(see [Templating](#templating)) actually produces something to report.

This composes with the regular flags, so an agent can still target a
specific request, substitute properties, or ask for a curl script instead
of executing the request:

```shell
# multiple requests in one payload, run the 2nd one
# a heredoc is the easiest way to hand over multi-line content
dothttp - --target 2 <<EOF
GET "https://httpbin.org/get"

POST "https://httpbin.org/post"
EOF

# substitute a property from the command line
echo 'GET "https://httpbin.org/get?key={{myprop}}"' \
  | dothttp - --property myprop=myvalue

# get a shareable curl command instead of executing the request
echo 'GET "https://httpbin.org/get"' | dothttp - --curl
```

Property-file auto-discovery (`.dothttp.json`/`.yaml`/`.yml`/`.toml` in the
current directory) still works in stdin mode, since it's resolved relative
to the working directory the command is run from — handy for agents that
run from within a project checkout.

An explicit `>> "path/to/file"` output directive inside the piped content
still writes to that file instead of stdout, same as file-based input.

#### Reusing existing request definitions (`import` + `@name(...) : base`)

An agent working inside a project usually doesn't need to reinvent auth,
headers, or retry/timeout settings for every new request — a project's
existing `.http` files already define them. **dothttp** supports `import`
and named request inheritance (`@name("child") : "base"`), so an agent's
stdin snippet can just import the file with the shared setup and extend it,
inheriting everything from the base and overriding only what's different
(the path, method, payload, etc).

For example, [`examples/inheritance_example.http`](./examples/inheritance_example.http)
already defines an `"api base"` request with a host, `Authorization` header,
`timeout`, and `retry` configured. An agent can reuse all of it with a
two-line snippet:

```shell
dothttp - --target "get repo" <<'EOF'
import "examples/inheritance_example.http";

@name("get repo") : "api base"
GET /repos/cedric05/dothttp
EOF
```

This resolves to `GET https://api.github.com/repos/cedric05/dothttp` with
the `Authorization`, `timeout`, and `retry` settings from `"api base"`
applied automatically — the agent never had to know or copy those details.
`import` paths (like `--property-file` auto-discovery above) are resolved
relative to the working directory the command is run from, so this works
best when the agent runs from the project root.

#### Custom and system trusted CAs

Client certificates and trusted server CAs are configured separately. Use
`trust(...)` to provide one CA certificate bundle for server verification:

```http
@name("internal api")
GET https://api.example.com
trust("/path/to/internal-root-ca.pem")
```

Trusted CA settings are inherited by child requests, as shown in
[`examples/trust_store.http`](./examples/trust_store.http). Requests fail
normally when the server is not trusted; `@insecure` is still the explicit
way to disable certificate verification.

```http
@name("system trust store")
@enable_trust_store
GET https://api.example.com
```

-----------
### Vscode alternatives

- [rest-client](https://marketplace.visualstudio.com/items?itemName=humao.rest-client) written in typescript
- [httpYac](https://marketplace.visualstudio.com/items?itemName=anweber.vscode-httpyac)  written in typescript
- [Thunder Client](https://marketplace.visualstudio.com/items?itemName=rangav.vscode-thunder-client) closed source

---------
### Non Vscode alternatives
- [http-client](https://www.jetbrains.com/help/idea/http-client-in-product-code-editor.html)  closed source
- [dothttp](https://github.com/tonsV2/dothttp)  written in python


