The system does not support requesting with HTTP/2. The idea is provide this support and adding as feedback in output when using the HTTP/2.

It's also wished some flag as --http2 for global requests commands, to force it to use HTTP2 only.

Come from: #18

To enhance the visual clarity of the output, it is proposed to implement syntax highlighting with JSON colors for both the payload and headers in the treq command. This improvement aims to provide a more well-formatted and visually appealing output, making it easier for users to interpret and analyze the information.

The current output of body....

The wished formatted body... Colorized and pretty to eyes

By default, TReq exits with 0 when no network or other fatal errors occur. This flag instructs TReq to also check the HTTP status code and exit with an error if the status indicates one.

When the server replies with a 4xx (Client Error) or 5xx (Server Error) status code, TReq exits with 4 or 5 respectively.

Beyond just basic response information, all data of request should to appear.

This task depend #22, because this will execute both command with --offline flag and normal command without it.

The objective is to replicate this feature in HTTPie (https://httpie.io/docs/cli/nested-json).

  people[name]=Peter  \
  people[about][job]=dev \
  people[about][country]=Brazil \
  people[about][age]:=27 \
  people[skills]:=["Rust", "Python"]
---
{
    "people": {
        "name": "Peter",
        "about": {
            "job": "dev",
            "country": "Brazil",
            "age": 27
        },
        "skills": [
            "Rust",
            "Python"
        ]
    }
}

Additional Considerations:

• Ensure that the introduced operator is clearly documented and explained in the treq documentation.
• Conduct thorough testing to verify the accurate inference of JSON types and proper integration with the existing treq command.
• Consider providing informative error messages in case of invalid JSON structures.
• Note: It does NOT necessary add the building arrays through [] suffix like this FIRST EXAMPLE in httpie doc or this example...

search[keywords][]=APIs \
search[keywords][]=CLI
---------
{
 "search": {
        "keywords": [
            "APIs",
            "CLI"
        ],
    }
}

Only focus in define nested values in this task.

In this initial version the TUI will be able to...

• View saved requests
• Edit saved requests data (with options to undo or redo)
• Create new saved requests

Basically a screen to make easier the CRUD of saved requests

Currently, when making a request through treq, the user experience during loading is limited to a spinner and the text "loading." To provide a more informative experience, it is proposed to add a timer during loading, indicating the elapsed time since the start of the request.

Additionally, in the response, it is suggested to include the response time next to the status code.
Here a example of ideia. This white baloon would be just text with 1.2 MS

The objective is to replicate the convenient localhost URL shortcut feature found in HTTPie (https://httpie.io/docs/cli/url-shortcuts-for-localhost). The proposal suggests introducing an alias of the form :PORT/ to streamline localhost URLs.

Instead of requiring users to type treq GET localhost:3000/route, they can now use the shorthand treq GET :3000/route.

Expected Behavior:

• Implement the :PORT/ alias for localhost URLs.

Possible Solution/Implementation

Currently the Url is stored as a single String. In RequestData entity. To facilitate the implementation of this and potential future solutions, it is recommended to replace this single string with a struct that comprehensively stores all URL information.

Url<'a> {
    protocol: Option<&str>, // The default would be "http"
    host: &str,
    port: Option<u16>,
    path: &str,
    query_params: Vec<(&str, &str)>,
    anchor: Option<&str>,
},

This struct should include a function (returning a Result) to parse a string into it, validating if the parameter can be constructed from this struct. This enhancement will not only accommodate the proposed alias feature but also opens the door for additional URL aliases in the future.

The objective is to replicate this feature in HTTPie (https://httpie.io/docs/cli/output-options).

Basically, nothing is showed instead the response body payload.

Additional Considerations:

If not exist, in CliInput add a bool field for this and use it for implementation.

There are two possible ways to do that then:

• Add a input validator. The validator should check the https field and updating the Url string for adding this protocol (if not yet).
• In parse_inputs_to_request_data you can add in final of function a step for check this field in CliInput and set the protocol in RequestData if it is None.

The objective is to replicate this feature in HTTPie: https://httpie.io/docs/cli/redirected-input

Accept user for passing request data is through redirected stdin (standard input)—piping.
Receiving the inputs from this method is similar to using --raw flag with the content passed in stdin.

treq PUT api.com/put < files/data.json

echo -n '{"name": "John"}' | http PATCH api.com/patch Auth:None

These three command are equivalent (consider the file.json with content as {"name": "Thales"})

treq POST api.com/post --raw '{"name": "Thales"}'
echo '{"name": "Thales"}' | treq POST api.com/post
treq POST api.com/post < file.json
cat file.json | treq POST api.com/post

Additional Considerations:

It's really important use the same abstraction used by --raw flag. That way is even possible to merge the input from this with request items.

This command

echo '{ "name": "John", "age": 21 }' | treq POST api.com/post job=dev role=admin

would request with body...

{ 
  "name": "John",
  "age": 21,
  "job": "dev",
  "role": "admin"
}

The objective is to replicate this feature in HTTPie (https://httpie.io/docs/cli/offline-mode). This will be applied in Basic request subcommand (like treq GET or treq POST) and treq run. When the --offline flag is used, instead build the request and submit it, the app should return the raw request would be made. This is useful when users want to check if the request he is gonna submit is right.

Additional Considerations:

It's necessary add a field in CliInput. Like "request_items" field another field called "request_options". The field should be passed to ViewCommandExecutor of Submit Request. There, should live a switch. It get and build request, and instead submit it, just prints it. Create a Executor just to this new behavior.

Implement a Docker container setup for the CLI app with the aim of simplifying deployment and enhancing user experience. The goal is to empower users to effortlessly run the app by issuing a single command, such as docker run my-app. The container should offer a seamless and user-friendly shell environment, allowing users to explore and try out the app without any hassle.

Expected Behavior:

• A proper setup with Containerfile (Dockerfile) and a pipeline for Github CI/CD to deploy container in Docker Hub
• The container should be small as possible. It would not be great users download 300mb of an Docker image just to test a CLI.
• Document in README explicitly guiding users on how to effortlessly "give it a try" using this method. Provide a step-by-step guide for a smooth onboarding experience.
• There are already some setups using Container with "Containerfiles" at tests/ directory in main folder.

To replicate...

# 1. This post will send the payload json { "user": "Peter", "passoword" : "123" }
treq POST url.com user=Peter passoword=123 --save-as login

# 2. Running this command will send the same above payload
treq run login

# 3. Running this will send payload => { "passwork": "12345" }
treq run login password=12345

# In 3 step payload SHOULD BE = { "user": "Peter", "passoword" : "12345" }
#  appending the new "password" field and keeping all the fields saved before.

The current behavior when using body definition operator in run or edit command is replace all body already saved with the construct in inputs, instead using already saved body only appending the input fields.

Currently, the repo does not have any documentation for the source codes.

It is better to create documentation for each file.

• view source code
• utils source code
• app source code

Description

To elevate the user experience, the proposal is to introduce an auto-complete feature

At present, the system lacks inherent auto-completion functionality. This addition aims to assist users in seamlessly completing commands, thereby improving their interaction with the software, reducing the likelihood of errors, and enhancing overall efficiency.

Expected Behavior

• Provide auto-complete for all subcommands and flags.
• Provide auto-complete for flags like --url and --method.
• For flags like --method, provide auto-completion with possible unique values. (POST | GET | PUT ....)

Possible Solution/Implementation

Since the project utilizes Clap for managing the CLI interface, the proposed solution involves configuring or extending its features. Auto-completing saved requests can be achieved by reading the names of all files in {DATA_FOLDER}/collections/.

When new tags (releases) are published the pipeline should....

• Run all tests like CI pipeline already did
• Compile TReq binary, using musl target for create a binary with static linked deps
• Generate a .deb
• Insert these files (binary and .deb) in release assets

Invalid non-string values like key:={"name":] are parsed for normal string values, because they match in regex of body-value

^(?<key>[ -~]+)=(?<value>[ -~]+)$

The problem is here.... As the parsers_request_items::non_string_body_value return a None (as it not parse it), the next function accept.

When trying to run a request against an HTTP/2 site, I am met with the following error:

`----------------------------------------
GET https://http2site.com

Error Requesting...
error sending request for url (https://http2site.com/): http2 error: stream error detected: unspecific protocol error detected
`

This flag does not affect the execution of the command. However, it does not produce any output in the terminal.

It is important to note that if the command returns an error, it will still be displayed. If the process and command are successful, no output is shown.

The objective is to replicate this feature in HTTPie (https://httpie.io/docs/cli/file-based-separators).

The goal it is: instead of using a static string as the value for some header, you can use :@ operator to pass the desired value from a file.
Example, let's suppose I cd in a folder with a data.json file with content { "email": "...", "password": "..." } and a file "name.txt" with content as just Thales. You'll can...

treq POST httpbin.org/post \
    [email protected]               # Read a data field’s value from a file
    datas:[email protected]        # Embed a JSON object from a file
    X-Data:@files/another-file.txt             # Read a header from a file
    token==@files/token.txt             # Read a query parameter from a file

Additional Considerations:

This handler should live in input parsers to request data.

It must exist a function to receive input of "file path" and reader it, returning the String of content. This function would be called inside functions of parsers_request_items (that should pass to it the value they extracted from their input).

The current behavior of the treq command allows the execution of a request when a subcommand is omitted, potentially leading to confusion. For example, both treq GET url.com and treq url.com execute the same command. However, if the user mistypes a subcommand (e.g., treq GE url.com), it interprets the mistyped text as the URL and additional parameters, submitting a GET request for http://GE and attempting to validate url.com as a Request item.

The proposal is to implement a command validator specifically for default command requests (no subcommand provided). This validator will check for potential mistyped subcommands. If the entered command closely resembles a valid subcommand, provide a helpful suggestion to the user before executing the command.

Expected Behavior:

• Implement a command validator to identify potential mistyped subcommands for default command requests.
• Provide suggestions for valid subcommands using string distance calculation (Levenshtein distance).
• Optionally, continue execution only if the user confirms the suggested correction. (Consider implementing a flag like --no-confirm to skip the confirmation prompt and only display a warning.)

Additional Considerations:

• Ensure that the string distance calculation is case-insensitive. For example, when a user types treq get or treq GEt, the recommendation to type GET should appear, regardless of the casing.
• Provide a nice and clear output warning for this help.
• Conduct thorough testing to verify the accurate of String distance algorithm

The current state of the project lacks comprehensive manual documentation for the man treq command.

Expected Deliverables:

• Inclusion of usage examples and best practices for effective utilization of treq.
• Clear explanations of available commands, subcommands, and their respective flags.
• A well-structured and comprehensive manual documentation accessible through the man treq commands.

Implement a new command that allows users to remove saved requests from the system.

treq remove my-request

Expected Behavior:

• Introduce a new command treq remove to remove saved requests.
• Confirmation Mechanism: Implement a confirmation step to avoid accidental removal of requests.
• Consider implementing a flag like --no-confirm to skip the confirmation prompt

Implement a new command that allows users to rename saved requests from the system.

treq rename my-request new-name

You can imagine this command as the same thing of this below, without doing request...

treq run my-request --save-as new-name

Expected Behavior:

• Introduce a new command treq rename to edit name of saved requests without submit it.
• Confirmation Mechanism: Implement a confirmation step to avoid accidental rename of requests
• Consider implementing a flag like --no-confirm to skip the confirmation prompt

Enable auto-completion with saved requests. For commands such as run and inspect, when a user types , the system should complete with the names of saved requests.

That way, if user has a lot of saved request, the use of them turn easy.

Possible Solution/Implementation

Since the project utilizes Clap for managing the CLI interface, the proposed solution involves configuring or extending its features.

Auto-completing saved requests can be achieved by reading the NAME of all FILES in {DATA_FOLDER}/collections/. For linux the folder is $HOME/.local/share/treq/collections/.

When user execute TReq in a not TTY enviroment. Redirecting or piping output, like this...

treq url.com > file.txt # redirecting to
treq url.com | grep search-term

The TReq should check this and make the output the basic request output.

This check can be made by this function in Crossterm: https://docs.rs/crossterm/latest/crossterm/tty/trait.IsTty.html

Additional Considerations:

Use the same command options of using --body flag. Make the check of tty in beginning. If it's true, set like user pass the command with this flag. It is the same behavior.

It's also important does not ignore another flags like --header. So, this verification should be the last priority possible in all validation.

The objective is to replicate this feature in HTTPie (https://httpie.io/docs/cli/non-string-json-fields). The proposal suggests introducing a new operator in Request items to add JSON field. Instead of the traditional key=value syntax, users can utilize key:=value. This new separator is designed to automatically infer the type of the field when it's a non-string.

  age:=29                           # Raw JSON — Number
  married:=false                    # Raw JSON — Boolean
  hobbies:='["http", "pies"]'       # Raw JSON — Array
  favorite:='{"tool": "HTTPie"}'    # Raw JSON — Object

Expected Behavior

Implement type inference for the following JSON types

• Number
• Boolean (accepting trueor false as values)
• Objects (leveraging the same validations and parser as the --raw flag)
• Array (equivalent implementation to Objects)

Additional Considerations:

• Ensure that the introduced operator is clearly documented and explained in the treq documentation.
• Conduct thorough testing to verify the accurate inference of JSON types and proper integration with the existing treq command.
• Consider providing informative error messages in case of invalid JSON structures.