HTTP-API-Client

 view release on metacpan or  search on metacpan

Changes  view on Meta::CPAN

    + fix: RETRY_FAIL_STATUS crashed (wrong method name, decode_content vs
      decoded_content) any time it was actually used - the body-pattern-match
      it was trying to do was never wired up either, retry now happens purely
      on status-code match as the POD has always documented (HAC-009)
    + fix: kvp_response() crashed if called before any request was made -
      now returns {} like json_response() already did (HAC-007)
    + fix: convert_data() silently stringified a data hashref as 'HASH(0x...)'
      for any content_type other than json/form-urlencoded - now returns an
      empty body for empty data, dies with a clear message otherwise (HAC-008)
    + fix: a non-GET request (POST/PUT/DELETE) with application/x-www-form-urlencoded
      content-type and empty data never built an HTTP::Request object and crashed
      in send() - now builds an empty-content request correctly (HAC-004)
    + fix: send() slept RETRY_DELAY seconds on every failed request even with
      RETRY_FAIL_RESPONSE=0 (the default, no retries) - now returns immediately
      when no retry attempt is left (HAC-006)
    + license changed to MIT
    + Devel::Cover wired up as a develop-phase dependency, coverage documented in README

2021-03-31 - v1.03
    + use lazy builder, so the sub classes can just overwrite the _build_ sub instead of using default => sub {}

lib/HTTP/API/Client.pm  view on Meta::CPAN

are both unset. Default from C<HTTP_AUTH_TOKEN>.

=item content_type

Forces the request content type. Left unset, GET defaults to
C<application/x-www-form-urlencoded> and every other method defaults to
C<application/json; charset=$charset>.

=item charset

Used to build the default JSON content-type header and to decide whether
UTF-8 byte-encoding is applied to the request body. Default C<utf8>, from
C<HTTP_CHARSET>. Must be a real L<JSON::XS> charset method name (C<utf8>,
C<latin1>, C<ascii>, ...) - an invalid value dies immediately and clearly,
naming the bad value, the next time C<kvp2json()> is called, whether or
not C<json> has already been built.

=item timeout

Request timeout in seconds, passed to the underlying L<LWP::UserAgent>.
Default C<60>, from C<HTTP_TIMEOUT>. Re-applied to C<ua> at the start of

lib/HTTP/API/Client.pm  view on Meta::CPAN

a query string via C<kvp2str()> if it is C<application/x-www-form-urlencoded>
optionally followed by a C<;>-separated parameter (e.g. C<< application/
x-www-form-urlencoded; charset=utf-8 >> - the same charset-suffix pattern
this module's own JSON default already uses). Any other content type
returns an empty string for empty data, or dies naming the content type -
there is no generic way to serialize arbitrary data into an arbitrary
content type.

=head2 prepare_request(%options)

Builds the bare L<HTTP::Request> (method, URL, content-type header) and
applies authentication: C<username>/C<password> take priority and are sent
as HTTP Basic auth via C<basic_authenticator()>; C<auth_token> is used only
if neither is set, and is sent as a raw C<Authorization> header value
verbatim (no C<Bearer> prefix is added for you - include it in the token
itself if the API expects one). C<auth_token> only supplies a I<default>
C<Authorization> header - an explicit one already present in C<%headers>
for this call (any casing: C<Authorization>, C<authorization>, ...) is
left alone rather than overwritten. Called by C<new_request()> - there is
normally no need to call this directly.

t/07_empty_post.t  view on Meta::CPAN

=head1 NAME

07_empty_post.t - regression test for HAC-004: a non-GET request with
form-urlencoded content-type and empty data must still build a real
HTTP::Request instead of leaving it undef

=cut

use strict;
use warnings;
use Test::More;
use HTTP::API::Client;

my $api = HTTP::API::Client->new( content_type => "application/x-www-form-urlencoded" );

my $request = $api->post("http://example.com/action", {}, {}, {
    test_request_object => 1,
});

ok defined($request), "POST with empty data and form-urlencoded content-type still builds a request";
isa_ok $request, "HTTP::Request";
is $request->method, "POST", "method is POST";
is $request->content, '', "content is empty";

done_testing;