Posting is a powerful HTTP client that lives in your terminal.
It works over SSH, stores collections locally in a simple (and Git-friendly) YAML format, and can be operated efficiently using both keyboard and mouse.
![image](https://private-user-images.githubusercontent.com/5740731/346749826-77f50aa0-bc93-4e42-b06b-c209ec233fe8.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjU3MzAwMjMsIm5iZiI6MTcyNTcyOTcyMywicGF0aCI6Ii81NzQwNzMxLzM0Njc0OTgyNi03N2Y1MGFhMC1iYzkzLTRlNDItYjA2Yi1jMjA5ZWMyMzNmZTgucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI0MDkwNyUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNDA5MDdUMTcyMjAzWiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9NjBjYTNkYmYxNmU4YTdkZDE0MmE3YjJiMTcyYzI2YWI3MDI1YTI0NGMyNWFhN2YwYzM4OTU5NDk3NjIzYmQ5OCZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QmYWN0b3JfaWQ9MCZrZXlfaWQ9MCZyZXBvX2lkPTAifQ.LjYuuGpnuV_c2uv24sh-nJUVM9NKQxT2_dCv2lI9UmE)
Posting can be installed via pipx
:
pipx install posting
Python 3.11 or later is required.
More installation methods (brew
, etc) will be added soon.
Requests can be stored directly on your file system.
Each request is stored as a simple YAML file, suffixed with .posting.yaml
- easy to read, understand, and version control!
Here's a quick example of a *.posting.yaml
file.
name: Create user
description: Adds a new user to the system.
method: POST
url: https://jsonplaceholder.typicode.com/users
body:
content: |-
{
"firstName": "John",
"lastName": "Doe",
"email": "[email protected]"
}
headers:
- name: Content-Type
value: application/json
- name: Some-Header
value: Some value
enabled: false
params:
- name: sendWelcomeEmail
value: 'true'
To open a collection (a directory containing requests), use the --collection
option:
posting --collection path/to/collection
This will recursively find and display requests in the sidebar.
If you don't supply a directory, Posting will use the default collection directory.
You can check where this is by running posting locate collection
.
- To create a new request, press ctrl+n.
- To save changes to the currently open request, press ctrl+s.
Posting can be navigated using either mouse or keyboard.
Jump mode is the fastest way to get around in Posting.
Press ctrl+o to enter jump mode.
A key overlay will appear on the screen, allowing you to jump to any widget by pressing the corresponding key.
![image](https://private-user-images.githubusercontent.com/5740731/345499659-0911e3da-7500-456f-a53f-ea5038498e13.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjU3MzAwMjMsIm5iZiI6MTcyNTcyOTcyMywicGF0aCI6Ii81NzQwNzMxLzM0NTQ5OTY1OS0wOTExZTNkYS03NTAwLTQ1NmYtYTUzZi1lYTUwMzg0OThlMTMucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI0MDkwNyUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNDA5MDdUMTcyMjAzWiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9NzhiMGI2OTliMzUzNjI0MmYwMDk1YTU3YzBmY2E2ZTdmYmJkZTdlMjU4Y2MyZjRkNGVmYWUwNTNhYjIzMzRiOSZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QmYWN0b3JfaWQ9MCZrZXlfaWQ9MCZyZXBvX2lkPTAifQ.Z8lxWA-f_vfwueNggjPNDvEnzAchCffY_XHkhct0bmE)
tab and shift+tab will move focus between widgets, and j/k/up/down will move around within a widget.
Where it makes sense, up and down will move between widgets.
Important keyboard shortcuts are displayed at the bottom of the screen.
Tip
Many parts of the Posting UI support Vim keys for navigation.
Some less important shortcuts are not shown in the footer. Many of these are documented below.
Action | Shortcut | Context |
---|---|---|
Focus the URL bar | ctrl+l | Global |
Toggle collection browser sidebar | ctrl+b | Global |
Expand request section | ctrl+m | When request section is focused |
Expand response section | ctrl+m | When response section is focused |
Next directory | shift+j | When collection browser is focused |
Previous directory | shift+k | When collection browser is focused |
Undo in request body | ctrl+z | When request body text area is focused |
Redo in request body | ctrl+y | When request body text area is focused |
Copy selection to clipboard | y or c | When response body text area is focused |
Open in pager | f3 | When a text area is focused |
Open in external editor | f4 | When a text area is focused |
Note
This section is incomplete. Many keyboard shortcuts are not yet documented.
Press ctrl+m to expand the section which currently has focus (the request or response section).
Press it again to reset the UI.
This can also be done via the command palette options view: expand request
and view: expand response
.
You can use variables in the UI using the ${VARIABLE_NAME}
or $VARIABLE_NAME
syntax.
These variables will be substituted into outgoing requests.
.env
files can be loaded using the --env
option.
Variables from these files can then be used in the UI.
Imagine you're testing an API which exists in both dev
and prod
environments.
The dev
and prod
environments share some common variables, but differ in many ways too.
We can model this by having a single shared.env
file which contains variables which are shared between environments, and then a dev.env
and prod.env
file which contain environment specific variables.
# file: shared.env
API_PATH="/api/v1"
ENV_NAME="shared"
# file: dev.env
API_KEY="dev-api-key"
ENV_NAME="dev"
BASE_URL="https://${ENV_NAME}.example.com"
# file: prod.env
API_KEY="prod-api-key"
ENV_NAME="prod"
BASE_URL="https://${ENV_NAME}.example.com"
When working in the dev
environment, you can then load all of the shared variables and all of the development environment specific variables using the --env
option:
posting --env shared.env --env dev.env
This will load all of the shared variables from shared.env
, and then load the variables from dev.env
. Since ENV_NAME
appears in both files, the value from the dev.env
file will be used since that was the last one specified.
Note that you do not need to restart to load changes made to these files, so you can open and edit your env files in an editor of your choice alongside Posting. However, autocompletion and variable highlighting will not update until Posting is restarted.
If you want to permit using environment variables that exist on the host machine (i.e. those which are not defined in any .env
files), you must set the use_host_environment
config option to true
(or set the environment variable POSTING_USE_HOST_ENVIRONMENT=true
).
Since all Posting configuration options can also be specified as environment variables, we can also put environment specific config inside .env
files. There's a dedicated "Configuration" section in this document which covers this in more detail.
For example, if you wanted to use a light theme in the prod environment (as a subtle reminder that you're in production!), you could set the environment variable POSTING_THEME=solarized-light
inside the prod.env
file.
Note that configuration files take precedence over environment variables, so if you set a value in both a .env
file and a config.yaml
, the value from the config.yaml
file will be used.
Some functionality in Posting doesn't warrant a dedicated keyboard shortcut (for example, switching to a specific theme), and can instead be accessed via the command palette.
To open the command palette, press ctrl+p.
Posting can be configured using a configuration file, environment variables, and/or .env
files.
Configuration values are loaded in the following order of precedence (highest to lowest):
- Configuration file
- Environment variables
.env
files
The range of available configuration will be greatly expanded in the future.
You can write configuration for Posting using YAML.
The location of the config file can be checked using the command posting locate config
.
Here's an example configuration file:
theme: galaxy
layout: horizontal
response:
prettify_json: false
heading:
visible: true
show_host: false
All configuration values can also be set as environment variables.
Simply prefix the name of the config with POSTING_
and set it as an environment variable.
For nested configuration values, use __
as the delimiter. So to set heading.visible
to false
, you can set the environment variable POSTING_HEADING__VISIBLE=false
.
For example, to set the theme to galaxy
, you can set the environment variable POSTING_THEME=galaxy
.
Posting also supports .env
(dotenv) files, which are useful if you want to keep your configuration in a file rather than in your shell's environment variables.
You can tell Posting to use a .env
file using the --env-file
option.
Here's an example .env
file:
POSTING_THEME="cobalt"
POSTING_LAYOUT="vertical"
POSTING_HEADING__VISIBLE="false"
Config Key (Env Var) | Values (Default) | Description |
---|---|---|
theme (POSTING_THEME ) |
"posting" , "galaxy" , "monokai" , "solarized-light" , "nautilus" , "nebula" , "alpine" , "cobalt" , "twilight" , "hacker" (Default: "posting" ) |
Sets the theme of the application. |
layout (POSTING_LAYOUT ) |
"vertical" , "horizontal" (Default: "horizontal" ) |
Sets the layout of the application. |
use_host_environment (POSTING_USE_HOST_ENVIRONMENT ) |
true , false (Default: false ) |
Allow/deny using environment variables from the host machine in requests via $env: syntax. When disabled, only variables defined explicitly in .env files will be available for use. |
animation (POSTING_ANIMATION ) |
"none" , "basic" , "full" (Default: "none" ) |
Controls the animation level. |
response.prettify_json (POSTING_RESPONSE__PRETTIFY_JSON ) |
true , false (Default: true ) |
If enabled, JSON responses will be pretty-formatted. |
heading.visible (POSTING_HEADING__VISIBLE ) |
true , false (Default: true ) |
Show/hide the app header. |
heading.show_host (POSTING_HEADING__SHOW_HOST ) |
true , false (Default: true ) |
Show/hide the hostname in the app header. |
url_bar.show_value_preview (POSTING_URL_BAR__SHOW_VALUE_PREVIEW ) |
true , false (Default: true ) |
Show/hide the variable value preview below the URL bar. |
Note: this feature is highly experimental.
Posting can convert OpenAPI 3.x specs into collections.
To import an OpenAPI Specification, use the posting import path/to/openapi.yaml
command.
You can optionally supply an output directory.
If no output directory is supplied, the default collection directory will be used.
Posting will attempt to build a file structure in the collection that aligns with the URL structure of the imported API.