view release on metacpan or  search on metacpan

README  view on Meta::CPAN

    All arguments after the first will be treated as query parameters (for
    GET/HEAD/DELETE requests) or request content (for POST/PUT requests).
    For instance:

            http://my-server.com> GET /products limit=10 offset=20
      # request goes to http://my-sever.com/products?limit=10&offset=20
    
            http://my-server.com> POST /products '{"name":"A New Product"}'
      # request goes to http://my-sever.com/products with the body as specified

    You can also specify additional headers you would like included in the
    request:

            # the ":" is optional
            http://my-server.com> header Accept: application/json
    
            # shortcut for "header Content-Type application/json"
            http://my-server.com> type application/json
    
            # shortcut for "header Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
            http://my-server.com> authorization Aladdin 'open sesame'
    
            # view all headers
            http://my-server.com> headers
    
            # view specific header
            http://my-server.com> header Authorization
    
            # clear all headers
            http://my-server.com> headers --clear
    
            # unset specific header
            http://my-server.com> header --unset Authorization

    If you are creating form URL-encoded data, a shortcut has been made to
    avoid having to manually URL-encode everything manually:

            http://my-server.com> form foo=bar baz=1,2,3
    
            # outputs
            foo=bar&baz=1%2C2%2C3

 Response Handling

    By default, presto will just dump the response body to the screen after
    a request is completed. There are additional options, however:

            # dump full request/response to the screen (exactly as transmitted over the wire)
            http://my-server.com> config verbose 1
    
            # parse the response according to the content-type and use
            # Data::Dumper to display it
            http://my-server.com> config deserialize_response 1
    
            # use something other than Data::Dumper to dump a parsed
            # response body
            http://my-server.com> config pretty_printer JSON
            http://my-server.com> config pretty_printer Data::Dump
    
            # send the output to a file (the '>' must not be followed by any white-space!)
            http://my-server.com> GET /some-image.png >some-image.png

    Pretty-printing can be especially helpful for making XML or JSON
    response bodies more human-readable.

    When deserialize_response is set, if the content-type of the response
    is "text/html", the HTML is automatically stripped with
    HTML::FormatText::WithLinks and displayed as formatted text.

    If the request or response body is binary (using a simple heuristic
    like the -B file-test operator), the output is not printed to STDOUT.
    Instead, you may want to use output redirection as show above and send
    the response body to a file.

            http://my-server.com> GET /some-image.jpg >foo.jpg

 Persistent Configuration

    As demonstrated above, you can use the config command to change the
    behavior of presto. These configuration options are persisted in a
    config file specific to the endpoint provided at the command-line and
    will be reloaded the next time you invoke presto with the same
    endpoint.

    Current valid config keys are:

      * verbose

      Boolean, when enabled, dumps request/response to STDOUT (defaults to
      "0")

      * deserialize_response

      Boolean, when enabled response body is parsed based on the
      Content-Type header (defaults to "1")

      * pretty_printer

      Must be one of the supported modules (i.e. Data::Dumper or JSON). Use
      tab completion to see currently supported values (defaults to
      "JSON").

      * binmode

      Used to set encoding of STDIN and STDOUT handles (defaults to "utf8")

    TODO: provide a means for aliasing endpoints so that configuration is
    shared across multiple endpoints.

 History and Scripting

    Just like configuration, command history is maintained separately for
    each endpoint specified on the command-line and is persisted across
    sessions (assuming you have a capable Term::Readline library
    installed). You can interrogate the history using the (surprisingly
    named) history command. It supports a small subset of the bash history
    command:

            # dump all history
            http://my-server.com> history