-
httpie
🥧 HTTPie CLI — modern, user-friendly command-line HTTP client for the API era. JSON support, colors, sessions, downloads, plugins & more. (by httpie)
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
libcurl
A command line tool and library for transferring data with URL syntax, supporting DICT, FILE, FTP, FTPS, GOPHER, GOPHERS, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, MQTT, POP3, POP3S, RTMP, RTMPS, RTSP, SCP, SFTP, SMB, SMBS, SMTP, SMTPS, TELNET, TFTP, WS and WSS. libcurl offers a myriad of powerful features
-
-
Reject-POSUCKS-embrace-Nushell
Don't be scared by the edgy title, the article is more substantive, I promise.
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
-
-
We did look at `jo`, and also `jarg`[0], the W3C HTML JSON form syntax[1], and pretty much every other approach we could find. We had quite a few requirements that the syntax had to meet: be simple/flexible, easy to read/write, backward/forward compatible, and play well with the rest of the HTTPie request language.
The final syntax is heavily inspired by the HTML JSON forms one. But we made it stricter, added type safety, and some other features. It supports all the existing functionality like embedding raw JSON strings and JSON/text files by paths.
The final implementation[2] is completely custom. We’ve plans to ship it as a standalone tool as well, publish the test suite in a language-independent format and write a formal spec so that other tools can easily adopt it. This spec will eventually be a subset of one for the overall HTTPie request language, which is currently tied to our CLI implementation but we want to decouple it.
Happy to hear you like the desktop app!
[0] https://github.com/jdp/jarg
[1] https://www.w3.org/TR/html-json-forms/
[2] https://github.com/httpie/httpie/blob/master/httpie/cli/nest...
This is cool.
In the spirit of "do one thing well", I'd so rather use this to construct JSON payloads to curl requests than the curl project's own "json part" proposal[1] under consideration.
[1]: https://github.com/curl/curl/wiki/JSON#--jp-part
There's also jshon which is a simple stack-based DSL for constructing JSON from shell scripts.
http://kmkeen.com/jshon/
It's written in C and is not actively developed. The latest commit, it seems, was a pull request from me back in 2018 that fixed a null-termination issue that led to memory corruption.
Because I couldn't rely on jshon being correct, I rewrote it in Haskell here:
https://github.com/dapphub/dapptools/tree/master/src/jays
This is also not developed actively but it's a single simple ~200 line Haskell program.
And I just use Nushell. You have built-ins to create (and parse) not only json but also url, xml and more... https://github.com/skelly37/Reject-POSUCKS-embrace-Nushell#b...
"Even though Python isn't the fastest language out there, it's likely still faster than the shell command above."
That is going a bit far. By all means use Python. Go ahead and attack people who use the shell. But let's be honest. The shell is faster, assuming one knows how to use it. A similar claim is often made by Python advocates, something along the lines of Python is not slow if one knows how to use it.
The startup time of a Python interpreter is enormous for someone who is used to a Bourne shell. This is what always stops me from using Python. If anyone knows how to mitigate that delay, feel free to share.
Anyway, this "jo" thing seems a bit silly. Someone at Google spent their 20% time writing a language called jsonnet to emit JSON. It has been discussed on HN before. People have suggested dhall is a perhaps better alternative.
https://jsonnet.org
https://dhall-lang.org
"Even though Python isn't the fastest language out there, it's likely still faster than the shell command above."
That is going a bit far. By all means use Python. Go ahead and attack people who use the shell. But let's be honest. The shell is faster, assuming one knows how to use it. A similar claim is often made by Python advocates, something along the lines of Python is not slow if one knows how to use it.
The startup time of a Python interpreter is enormous for someone who is used to a Bourne shell. This is what always stops me from using Python. If anyone knows how to mitigate that delay, feel free to share.
Anyway, this "jo" thing seems a bit silly. Someone at Google spent their 20% time writing a language called jsonnet to emit JSON. It has been discussed on HN before. People have suggested dhall is a perhaps better alternative.
https://jsonnet.org
https://dhall-lang.org
We did look at `jo`, and also `jarg`[0], the W3C HTML JSON form syntax[1], and pretty much every other approach we could find. We had quite a few requirements that the syntax had to meet: be simple/flexible, easy to read/write, backward/forward compatible, and play well with the rest of the HTTPie request language.
The final syntax is heavily inspired by the HTML JSON forms one. But we made it stricter, added type safety, and some other features. It supports all the existing functionality like embedding raw JSON strings and JSON/text files by paths.
The final implementation[2] is completely custom. We’ve plans to ship it as a standalone tool as well, publish the test suite in a language-independent format and write a formal spec so that other tools can easily adopt it. This spec will eventually be a subset of one for the overall HTTPie request language, which is currently tied to our CLI implementation but we want to decouple it.
Happy to hear you like the desktop app!
[0] https://github.com/jdp/jarg
[1] https://www.w3.org/TR/html-json-forms/
[2] https://github.com/httpie/httpie/blob/master/httpie/cli/nest...
Ended up sniping myself . Made a fairly complete version of what I was imagining: https://github.com/itsjohncs/construct-json#readme