App-Adenosine
view release on metacpan or search on metacpan
requests, until the next time the resty command is called.
1.4 2011-03-08
- Finalized bug fix for zsh users.
1.3 2011-03-04
- Attempted bug fix for zsh users that prevented options from being passed
correctly to curl.
1.2 2011-02-06
- Data is now optional in PUT and POST requests. If the input is not a
terminal and no data is specified on the command line, resty won't wait
for data on stdin anymore. If you liked the old behavior you can always do
something like `cat | POST /Somewhere` for the same effect.
1.1 2011-01-07
- Fixed bug where -V option required input on stdin, and would block waiting
for it.
Description
Adenosine is a tiny script wrapper for curl <http://curl.haxx.se/>. It
provides a simple, concise shell interface for interacting with REST
<http://en.wikipedia.org/wiki/Representational_State_Transfer>
services. Since it is just a command you run in your shell and not in
its own separate command environment you have access to all the
powerful shell tools, such as perl, awk, grep, sed, etc. You can use
adenosine in pipelines to process data from REST services, and PUT or
POST the data right back. You can even pipe the data in and then edit
it interactively in your text editor prior to PUT or POST.
Cookies are supported automatically and stored in a file locally. Most
of the arguments are remembered from one call to the next to save
typing. It has pretty good defaults for most purposes. Additionally,
adenosine allows you to easily provide your own options to be passed
directly to curl, so even the most complex requests can be accomplished
with the minimum amount of command line pain.
Here is a nice screencast showing adenosine (née resty) in action
<http://jpmens.net/2010/04/26/resty/> (by Jan-Piet Mens).
this whenever you want to change hosts, anytime).
$ adenosine http://127.0.0.1:8080/data
http://127.0.0.1:8080/data*
Make some HTTP requests.
$ GET /blogs.json
[ {"id" : 1, "title" : "first post", "body" : "This is the first post"}, ... ]
$ PUT /blogs/2.json '{"id" : 2, "title" : "updated post", "body" : "This is the new."}'
{"id" : 2, "title" : "updated post", "body" : "This is the new."}
$ DELETE /blogs/2
$ POST /blogs.json '{"title" : "new post", "body" : "This is the new new."}'
{"id" : 204, "title" : "new post", "body" : "This is the new new."}
What's Next?
Check out some of the plugins available for adenosine! Right now
Usage
source adenosine-exports [-W] [remote] # load functions into shell !!!
adenosine [-v] # prints current request URI base !!!
adenosine <remote> [OPTIONS] # sets the base request URI !!!
HEAD [path] [OPTIONS] # HEAD request
OPTIONS [path] [OPTIONS] # OPTIONS request
GET [path] [OPTIONS] # GET request
DELETE [path] [OPTIONS] # DELETE request
PUT [path] [data] [OPTIONS] # PUT request
POST [path] [data] [OPTIONS] # POST request
TRACE [path] [OPTIONS] # TRACE request
PATCH [path] [OPTIONS] # PATCH request
Options:
-Q Don't URL encode the path.
-q <query> Send query string with the path. A '?' is prepended to
<query> and concatenated onto the <path>.
-W Don't write to history file (only when sourcing script). !!!
-V Edit the input data interactively in 'vi'. (PUT and POST
requests only, with data piped to stdin.)
-v Verbose output. When used with the adenosine command itself
this prints the saved curl options along with the current
URI base. Otherwise this is passed to curl for verbose
curl output.
<curl opt> Any curl options will be passed down to curl.
Configuration, Data File Locations
Adenosine creates a few files in either your ${XDG_CONFIG_HOME} and
$ mkdir -p "${XDG_CONFIG_HOME}/resty" "${XDG_DATA_HOME}/resty"
$ mv ~/.resty/c "${XDG_DATA_HOME}/resty"
$ mv ~/.resty/* "${XDG_CONFIG_HOME}/resty"
Request URI Base
The request URI base is what the eventual URI to which the requests
will be made is based on. Specifically, it is a URI that may contain
the * character one or more times. The * will be replaced with the path
parameter in the OPTIONS, HEAD, GET, POST, PUT, PATCH or DELETE request
as described above.
For example:
$ adenosine 'http://127.0.0.1:8080/data*.json'
http://127.0.0.1:8080/data*.json
and then
$ GET /5
rc file when resty starts up, but only if the $_resty_host environment
variable is not set. In this way you can make requests to different
hosts using resty from separate terminals, and have a different URI
base for each terminal.
If you want to see what the current URI base is, just run adenosine
with no arguments. The URI base will be printed to stdout.
The Optional Path Parameter
The HTTP verbs (OPTIONS, HEAD, GET, POST, PUT, PATCH and DELETE) first
argument is always an optional URI path. This path must always start
with a / character. If the path parameter is not provided on the
command line, adenosine will just use the last path it was provided
with. This "last path" is stored in an environment variable
($_resty_path), so each terminal basically has its !!! own "last path".
URL Encoding Of Path Parameter
Adenosine will always URL encode
<http://www.blooberry.com/indexdot/html/topics/urlencoding.htm> the
$ GET /blogs/47 -d 'param=foo' -d 'otherparam=bar' -G
However, if you want to pass both GET parameters in the query string
and POST parameters in the request body, curl cannot support this by
itself. Using the -q or -Q adenosine options with the -d curl option
will accomplish this, like so:
$ POST '/blogs/47?param=foo&otherparam=bar' -Q -d 'postparam=baz'
POST/PUT Requests and Data
Normally you would probably want to provide the request body data right
on the command line like this:
$ PUT /blogs/5.json '{"title" : "hello", "body" : "this is it"}'
But sometimes you will want to send the request body from a file
instead. To do that you pipe in the contents of the file:
$ PUT /blogs/5.json < /tmp/t # !!!
Or you can pipe the data from another program, like this:
$ myprog | PUT /blogs/5.json # !!!
Or, interestingly, as a filter pipeline with
jsawk|http://github.com/micha/jsawk:
$ GET /blogs/5.json | jsawk 'this.author="Bob Smith";this.tags.push("news")' | PUT
Notice how the path argument is omitted from the PUT command.
Edit PUT/POST Data In Vi
With the -V options you can pipe data into PUT or POST, edit it in vi,
save the data (using :wq in vi, as normal) and the resulting data is
then PUT or POSTed. This is similar to the way visudo works, for
example.
$ GET /blogs/2 | PUT -V
This fetches the data and lets you edit it, and then does a PUT on the
resource. If you don't like vi you can specify your preferred editor by
setting the EDITOR environment variable.
Errors and Output
For successful 2xx responses, the response body is printed on stdout.
You can pipe the output to stuff, process it, and then pipe it back to
adenosine, if you want.
For responses other than 2xx the response body is dumped to stderr.
list is reset.
Per-Host/Per-Method Curl Configuration Files
Adenosine supports a per-host/per-method configuration file to help you
with frequently used curl options. Each host (including the port) can
have its own configuration file in the ~/.resty directory. The file
format is
$ GET [arg] [arg] ...
$ PUT [arg] [arg] ...
$ POST [arg] [arg] ...
$ DELETE [arg] [arg] ...
Where the args are curl command line arguments. Each line can specify
arguments for that HTTP verb only, and all lines are optional.
So, suppose you find yourself using the same curl options over and
over. You can save them in a file and adenosine will pass them to curl
for you. Say this is a frequent pattern for you:
functions. However, it's likely that you don't want it to be
overwriting the adenosine host history file, and you will almost always
want to set the URI base explicitly.
#!/usr/bin/env bash
# Load adenosine, don't write to the history file, and set the URI base
. /path/to/adenosine-exports -W 'https://myhost.com/data*.json'
# GET the JSON list of users, set each of their 'disabled' properties
# to 'false', and PUT the modified JSON back
GET /users | jsawk 'this.disabled = false' | PUT
Here the -W option was used when loading the script to prevent writing
to the history file and an initial URI base was set at the same time.
Then a JSON file was fetched, edited using jsawk
<http://github.com/micha/jsawk>, and re-uploaded to the server.
Application Configuration
Adenosine may be configured by placing a YAML document in
~/.adenosinerc.yml. More parts of adenosine will be configurable as
adenosine-exports view on Meta::CPAN
function HEAD() { adenosine HEAD "$@" }
function OPTIONS() { adenosine OPTIONS "$@" }
function GET() { adenosine GET "$@" }
function POST() { adenosine POST "$@" }
function PUT() { adenosine PUT "$@" }
function DELETE() { adenosine DELETE "$@" }
function TRACE() { adenosine TRACE "$@" }
function PATCH() { adenosine PATCH "$@" }
export PATH="$PATH:$(cd $(dirname $0) && pwd)/bin"
bin/adenosine view on Meta::CPAN
version 2.002000
=head1 Description
Adenosine is a tiny script wrapper for L<curl|http://curl.haxx.se/>. It
provides a simple, concise shell interface for interacting with
L<REST|http://en.wikipedia.org/wiki/Representational_State_Transfer> services.
Since it is just a command you run in your shell and not in its own separate
command environment you have access to all the powerful shell tools, such
as perl, awk, grep, sed, etc. You can use adenosine in pipelines to process data
from REST services, and PUT or POST the data right back. You can even pipe
the data in and then edit it interactively in your text editor prior to PUT
or POST.
Cookies are supported automatically and stored in a file locally. Most of
the arguments are remembered from one call to the next to save typing. It
has pretty good defaults for most purposes. Additionally, adenosine allows you
to easily provide your own options to be passed directly to curl, so even
the most complex requests can be accomplished with the minimum amount of
command line pain.
L<Here is a nice screencast showing adenosine (née resty) in action|http://jpmens.net/2010/04/26/resty/>
bin/adenosine view on Meta::CPAN
whenever you want to change hosts, anytime).
$ adenosine http://127.0.0.1:8080/data
http://127.0.0.1:8080/data*
Make some HTTP requests.
$ GET /blogs.json
[ {"id" : 1, "title" : "first post", "body" : "This is the first post"}, ... ]
$ PUT /blogs/2.json '{"id" : 2, "title" : "updated post", "body" : "This is the new."}'
{"id" : 2, "title" : "updated post", "body" : "This is the new."}
$ DELETE /blogs/2
$ POST /blogs.json '{"title" : "new post", "body" : "This is the new new."}'
{"id" : 204, "title" : "new post", "body" : "This is the new new."}
=head1 What's Next?
Check out some of the plugins available for adenosine! Right now there's just
bin/adenosine view on Meta::CPAN
=head1 Usage
source adenosine-exports [-W] [remote] # load functions into shell !!!
adenosine [-v] # prints current request URI base !!!
adenosine <remote> [OPTIONS] # sets the base request URI !!!
HEAD [path] [OPTIONS] # HEAD request
OPTIONS [path] [OPTIONS] # OPTIONS request
GET [path] [OPTIONS] # GET request
DELETE [path] [OPTIONS] # DELETE request
PUT [path] [data] [OPTIONS] # PUT request
POST [path] [data] [OPTIONS] # POST request
TRACE [path] [OPTIONS] # TRACE request
PATCH [path] [OPTIONS] # PATCH request
Options:
-Q Don't URL encode the path.
-q <query> Send query string with the path. A '?' is prepended to
<query> and concatenated onto the <path>.
-W Don't write to history file (only when sourcing script). !!!
-V Edit the input data interactively in 'vi'. (PUT and POST
requests only, with data piped to stdin.)
-v Verbose output. When used with the adenosine command itself
this prints the saved curl options along with the current
URI base. Otherwise this is passed to curl for verbose
curl output.
<curl opt> Any curl options will be passed down to curl.
=head1 Configuration, Data File Locations
Adenosine creates a few files in either your C<${XDG_CONFIG_HOME}> and C<${XDG_DATA_HOME}>
bin/adenosine view on Meta::CPAN
$ mkdir -p "${XDG_CONFIG_HOME}/resty" "${XDG_DATA_HOME}/resty"
$ mv ~/.resty/c "${XDG_DATA_HOME}/resty"
$ mv ~/.resty/* "${XDG_CONFIG_HOME}/resty"
=head1 Request URI Base
The request URI base is what the eventual URI to which the requests will be
made is based on. Specifically, it is a URI that may contain the C<*> character
one or more times. The C<*> will be replaced with the C<path> parameter in the
C<OPTIONS>, C<HEAD>, C<GET>, C<POST>, C<PUT>, C<PATCH> or C<DELETE> request as
described above.
For example:
$ adenosine 'http://127.0.0.1:8080/data*.json'
http://127.0.0.1:8080/data*.json
and then
$ GET /5
bin/adenosine view on Meta::CPAN
(C<$_resty_host>). The URI base is read from the rc file when resty starts
up, but only if the C<$_resty_host> environment variable is not set.
In this way you can make requests to different hosts using resty from
separate terminals, and have a different URI base for each terminal.
If you want to see what the current URI base is, just run C<adenosine> with no
arguments. The URI base will be printed to stdout.
=head1 The Optional Path Parameter
The HTTP verbs (C<OPTIONS>, C<HEAD>, C<GET>, C<POST>, C<PUT>, C<PATCH> and
C<DELETE>) first argument is always
an optional URI path. This path must always start with a C</> character. If
the path parameter is not provided on the command line, adenosine will just use
the last path it was provided with. This "last path" is stored in an
environment variable (C<$_resty_path>), so each terminal basically has its C<!!!>
own "last path".
=head2 URL Encoding Of Path Parameter
Adenosine will always
bin/adenosine view on Meta::CPAN
$ GET /blogs/47 -d 'param=foo' -d 'otherparam=bar' -G
However, if you want to pass both GET parameters in the query string B<and>
POST parameters in the request body, curl cannot support this by itself.
Using the C<-q> or C<-Q> adenosine options with the C<-d> curl option will accomplish
this, like so:
$ POST '/blogs/47?param=foo&otherparam=bar' -Q -d 'postparam=baz'
=head1 POST/PUT Requests and Data
Normally you would probably want to provide the request body data right on
the command line like this:
$ PUT /blogs/5.json '{"title" : "hello", "body" : "this is it"}'
But sometimes you will want to send the request body from a file instead. To
do that you pipe in the contents of the file:
$ PUT /blogs/5.json < /tmp/t # !!!
Or you can pipe the data from another program, like this:
$ myprog | PUT /blogs/5.json # !!!
Or, interestingly, as a filter pipeline with
C<jsawk|http://github.com/micha/jsawk>:
$ GET /blogs/5.json | jsawk 'this.author="Bob Smith";this.tags.push("news")' | PUT
Notice how the C<path> argument is omitted from the C<PUT> command.
=head2 Edit PUT/POST Data In Vi
With the C<-V> options you can pipe data into C<PUT> or C<POST>, edit it in vi,
save the data (using C<:wq> in vi, as normal) and the resulting data is then
PUT or POSTed. This is similar to the way C<visudo> works, for example.
$ GET /blogs/2 | PUT -V
This fetches the data and lets you edit it, and then does a PUT on the
resource. If you don't like vi you can specify your preferred editor by
setting the C<EDITOR> environment variable.
=head1 Errors and Output
For successful 2xx responses, the response body is printed on stdout. You
can pipe the output to stuff, process it, and then pipe it back to adenosine,
if you want.
For responses other than 2xx the response body is dumped to stderr.
bin/adenosine view on Meta::CPAN
options automatically added. Each time adenosine is called this option list
is reset.
=head2 Per-Host/Per-Method Curl Configuration Files
Adenosine supports a per-host/per-method configuration file to help you with
frequently used curl options. Each host (including the port) can have its
own configuration file in the F<~/.resty> directory. The file format is
$ GET [arg] [arg] ...
$ PUT [arg] [arg] ...
$ POST [arg] [arg] ...
$ DELETE [arg] [arg] ...
Where the C<arg>s are curl command line arguments. Each line can specify
arguments for that HTTP verb only, and all lines are optional.
So, suppose you find yourself using the same curl options over and over. You
can save them in a file and adenosine will pass them to curl for you. Say this
is a frequent pattern for you:
bin/adenosine view on Meta::CPAN
functions. However, it's likely that you don't want it to be overwriting the
adenosine host history file, and you will almost always want to set the URI
base explicitly.
#!/usr/bin/env bash
# Load adenosine, don't write to the history file, and set the URI base
. /path/to/adenosine-exports -W 'https://myhost.com/data*.json'
# GET the JSON list of users, set each of their 'disabled' properties
# to 'false', and PUT the modified JSON back
GET /users | jsawk 'this.disabled = false' | PUT
Here the C<-W> option was used when loading the script to prevent writing
to the history file and an initial URI base was set at the same time. Then a
JSON file was fetched, edited using L<jsawk|http://github.com/micha/jsawk>,
and re-uploaded to the server.
=head1 Application Configuration
Adenosine may be configured by placing a C<YAML> document in
F<~/.adenosinerc.yml>. More parts of adenosine will be configurable as time
lib/App/Adenosine.pm view on Meta::CPAN
use URI;
use Getopt::Long qw(:config pass_through no_ignore_case);
use File::Path 'mkpath';
use URI::Escape 'uri_escape';
use File::Spec::Functions 'splitpath';
use Path::Class;
use Text::ParseWords;
use Scalar::Util 'blessed';
use Module::Runtime 'use_module';
our $verb_regex = '(?:HEAD|OPTIONS|GET|DELETE|PUT|POST|TRACE|PATCH)';
sub verbose { $_[0]->{verbose} }
sub plugins { @{$_[0]->{plugins}} }
sub enable_xdg {
return $_[0]->{enable_xdg} if exists $_[0]->{enable_xdg};
return 1
}
sub _plugin_name {
my ($self, $name) = @_;
lib/App/Adenosine.pm view on Meta::CPAN
GetOptions (
Q => sub { $quote = 0 },
"q=s" => \$query,
V => \$interactive_edit,
v => sub { $self->{verbose} = 1 },
);
my @extra = (@ARGV, $self->_get_extra_options);
my $wantdata;
$wantdata = 1 if $action =~ m/^(?:PUT|POST|TRACE|PATCH)$/;
if ($wantdata && $interactive_edit) {
require File::Temp;
my ($fh, $fn) = File::Temp::tempfile();
system($ENV{EDITOR} || 'vi', $fn);
$data = file($fn)->slurp;
unlink $fn;
}
lib/App/Adenosine.pm view on Meta::CPAN
$self->stderr(join(" ", map "'$_'", @curl) . "\n") if $self->verbose;
my ($out, $err, $ret) = $self->capture_curl(@curl);
return $self->handle_curl_output($out, $err, $ret);
} elsif ($action eq 'exports') {
print <<'SHELL';
function HEAD() { adenosine HEAD "$@"; };
function OPTIONS() { adenosine OPTIONS "$@"; };
function GET() { adenosine GET "$@"; };
function POST() { adenosine POST "$@"; };
function PUT() { adenosine PUT "$@"; };
function DELETE() { adenosine DELETE "$@"; };
function TRACE() { adenosine TRACE "$@"; };
function PATCH() { adenosine TRACE "$@"; };
SHELL
} else {
my $uri_base = $self->uri_base($action);
$self->_set_extra_options(@ARGV);
$self->stdout("$uri_base\n"), return
}
}
lib/App/Adenosine/Plugin/Rainbow.pm view on Meta::CPAN
default => sub { 'yellow' },
);
has request_ellided_body_color => (
is => 'ro',
default => sub { 'blue' },
);
our $timestamp_re = qr/^(.*?)(\d\d):(\d\d):(\d\d)\.(\d{6})(.*)$/;
# this is probably not right...
our $header_re = qr/^(.+?):\s*(.+)$/;
our $methods_re = qr/HEAD|PUT|POST|GET|DELETE|OPTIONS|TRACE/;
our $request_re = qr<^($methods_re) (.*) (HTTP)/(1\.[01])$>;
our $response_re = qr<^(HTTP)/(1\.[01]) (\d{3}) (.*)$>;
sub filter_request_ellided_body {
my ($self, $pre, $post) = @_;
if (my @m = $pre =~ $timestamp_re) {
$pre = $self->filter_timestamp(@m)
}
( run in 0.364 second using v1.01-cache-2.11-cpan-4e96b696675 )