Over the past few weeks, we’ve been heads-down working on our cloud backend for the HTTPie API platform that will soon enable many important features on our roadmap as well the integration of HTTPie for Web, Desktop, and gradually also Terminal.
At the same time, we also added browser preview to HTTPie for Web & Desktop, continued the streamlining of the library, added numerous improvements, and fixed some bugs. As for HTTPie for Terminal, we continued enhancing its UI, this time focusing on its help output.
Check out what’s new 👇
HTTPie for Web & Desktop
👁️ Rendered response body
Now you can see HTML responses like a human: rendered as if you were in a browser. It’s especially helpful when you’re debugging APIs and get back rich error pages, need to get through a CAPTCHA, etc.
When we detect an HTML body, the message view switches to “Browser”. You can switch back to source view by selecting “HTML” instead.
✊🖐️ Drag & drop in the library
The streamlining of the library continues. Now you can move requests around in the most intuitive: just drag and drop a request to a collection and you’re all set.
✨ Improvements
- Collections have their own tab, where you can manage their nested requests and access other features, like the collection auth. Now, when you create a new collection, its tab opens automatically.
- You can expand and collapse collections in the library panel as you wish. But when you are working on a request saved in a collection, you’ll most likely want it expanded. Now we expand it automatically for you when you activate its tab.
- Headers are now sorted by name and capitalized. Check them out in the request preview, and the request and response views.
🪲 Fixes
- The
Content-Length
header was not sent in the desktop app for requests with a body. That resulted inTransfer-Encoding: chunked
requests, which some servers don’t support. Fixed. - You couldn’t send a request after removing the body file in the desktop app. Now you can.
- When you’re building a form request, you can attach files as a value, and if the file is a textual one, you can embed its contents (just like HTTPie for Terminal). The embed toggle was buggy, however, which made it hard to operate. Now it’s usable again.
- You can choose to name a request; otherwise, the URL will be used dynamically to identify it. But if you duplicated a request without a name, then the URL would be set as a non-dynamic name. We’ve fixed it.
- You can use
⌘–Enter
(macOS) orControl–Enter
(elsewhere) to send the request you’re working on. But when you were editing the request body, it would also enter a new line. Now it doesn’t. - The panel resizer was overlapping the scrollbar, so you were unable to scroll in the request builder panel if it was long. Now you can.
- Booleans and nulls in JSON are now correctly syntax-highlighted again.
- There are tooltips all around to help you understand the interface. Some of them extended too long horizontally. Now they have a max-width and wrap up nicely.
HTTPie for Terminal
After the 3.0 release of HTTPie for Terminal, we’re preparing for 3.1. Here’s what’s new in the development version:
Simplified usage help (#1296)
HTTPie for Terminal grew a lot in the past decade, so did the usage section in the help messages:
$ http
usage: http
[--json] [--form] [--multipart] [--boundary BOUNDARY]
[--raw RAW] [--compress]
[--pretty {all,colors,format,none}] [--style STYLE]
[--unsorted] [--sorted] [--response-charset ENCODING]
[--response-mime MIME_TYPE]
[--format-options FORMAT_OPTIONS] [--print WHAT]
[--headers] [--meta] [--body] [--verbose] [--all]
[--history-print WHAT] [--stream] [--output FILE]
[--download] [--continue] [--quiet]
[--session SESSION_NAME_OR_PATH |
--session-read-only SESSION_NAME_OR_PATH]
[--auth USER[:PASS] | TOKEN]
[--auth-type {basic,bearer,digest,edgegrid}]
[--ignore-netrc] [--offline]
[--proxy PROTOCOL:PROXY_URL]
[--follow] [--max-redirects MAX_REDIRECTS]
[--max-headers MAX_HEADERS] [--timeout SECONDS]
[--check-status] [--path-as-is] [--chunked]
[--verify VERIFY] [--ssl {ssl2.3,tls1,tls1.1,tls1.2}]
[--ciphers CIPHERS] [--cert CERT] [--cert-key CERT_KEY]
[--ignore-stdin] [--help] [--version] [--traceback]
[--default-scheme DEFAULT_SCHEME] [--debug]
[METHOD] URL [REQUEST_ITEM ...]
http: error: the following arguments are required: URL
We redesigned this segment to be more simple, so it reveals what you really care about:
$ http
usage:
http [METHOD] URL [REQUEST_ITEM ...]
error:
the following arguments are required: URL
For more information try 'http --help'
It can also contextually highlight the usage of specific options. In the example below, it adds --pretty {all, colors, ...}
to the usage since you’ve just mistyped that option:
$ http --pretty
usage:
http [--pretty {all,colors,format,none}] [METHOD] URL [REQUEST_ITEM ...]
error:
argument --pretty: expected one argument
For more information try 'http --help'
✨ Improvements
- The
httpie cli export
command now applies the same prettification (coloring and auto-indenting) to the exported argument definition as it does to all other output. (#1293)
Happy testing, and see you next week!
But in the meantime…
- 💁🏻♀️ If you’re not on the private beta yet, you can join the waitlist here.
- 👉 You can also follow @httpie and join our Discord community.
- 👩💻 We’re looking for new colleagues in engineering and design roles.
Originally published on HTTPie blog.
Top comments (0)