For the hard-core curl fans I find these examples useful.
Posting in-line form data, e.g., to an api:
$ curl ‐d ‘hi there’ https://drjohns.com/api/example
Well, that might work, but I normally add more switches.
$ curl ‐iksv ‐d ‘hi there’ https://drjohns.com/api/example|more
Perhaps you have JSON data to POST and it would be awkward or impossible to stuff into the command line. You can read it from a file like this:
$ curl ‐iksv ‐d @json.txt https://drjohns.com/api/example|more
Perhaps you have to fake a useragent to avoid a web application firewall. It actually suffices to identify with the -A Mozilla/4.0 switch like this:
$ curl ‐A Mozilla/4.0 ‐iksv ‐d @json.txt https://drjohns.com/api/example|more
Suppose you are behind a proxy. Then you can tack on the -x switch like this next example.
$ curl ‐A Mozilla/4.0 ‐x myproxy:8080 ‐iksv ‐d @json.txt https://drjohns.com/api/example|more
Those are the main ones I use for POSTing data while seeing what is going on. You can also add a maximum time (-m I think).
If you’re sending JSON data, you ought to declare it with a content-type header:
$ curl ‐A Mozilla/4.0 ‐H ‘Content-type: application/json’ ‐iksv ‐d @json.txt https://drjohns.com/api/example|more
Just overhearing people talk, I believe that “normal” people use a tool called POSTman to do similar things: POST XML, SOAP or JSON data to an endpoint. I haven’t had a need to use it or even to look into it myself. yet.
We have documented some useful switches in curl. POSTing data occurs when using APIs, e.g., RESTful APIs, so these techniques are useful to master. Roadblocks thrown up by web application firewalls or proxy servers can also be easily overcome.