In the current API I have to override the path with the same method I also adjust the payload. This feels wrong as changing the path is first something super rare as it's against the principle of that package. And You don't do the request with a path but to a path. So an API like to(path: '/foo/bar') feels better. This could also allow adjusting the fragment and other URI segments.

When I am building a request with transporter, and it needs authentication, I typically add a method onto my Request that looks like:

public function authenticate(): static
{
    $this->request->withToken(config('services.service-name.token'));

  return $this;
}

Which allows me to use it on requests as required:

MyRequest::build()->authenticate()->send();

It works, and works well. But I can't help feel something is missing here. If we are really going for an OOP approach to API requests, surely there is something I could do here? My initial thoughts, that I would like some feedback on are:

class MyRequest extends Request
{
  protected AuthStrategy $authStrategy;

  public function send(): Response
  {
    $this->authStrategy->apply($this->request);
    
    /** Rest of method */
  }
}

Allowing us to create our own AuthStrategies as required:

interface AuthStrategy
{
  public function apply(PendingRequest $request): void;
}

Which allows:

class ApiTokenStrategy implements AuthStrategy
{
  public function __construct(
    protected string $token,
  ) {}

  public function apply(PendingRequest $request): void
  {
    $request->withToken($this->token);
  }
}

The last step is something I need to figure out, how to get it to be added nicely, I had thought perhaps a Trait - but I am not sure. I am open to suggestions from others here.

When calling withQuery(), it's possible to overwrite previous entries inadvertently.

Consider implementing a request that allows for JSON:API pagination using a page-based strategy. Perhaps you have the following methods:

    public function pageNumber(int $pageNumber)
    {
        $this->withQuery(['page' => ['number' => $pageNumber]]);

        return $this;
    }

    public function pageSize(int $pageSize)
    {
        $this->withQuery(['page' => ['size' => $pageSize]]);

        return $this;
    }

If withQuery() uses array_merge(), then the page key is always overwritten. So, if a user specifies the page number and then the page size, then $this->query will have the following value: ['page' => ['size' => ???]].

I believe changing array_merge() to array_merge_recursive() will resolve this.

I'm not 100% sure, but there may be reason to look into this with some of the other array-merging functionality.

Please let me know if you have any questions or concerns. 🤓

I'm currently debugging an issue and would like to see what exactly is being send to the third party API.

So is there any way to view the full raw output of what is being send?

Right now the default namespace is App\Http\API\Requests which at first looks cool but the classes inside are totally unrelated to my apps HTTP responsibilities. These are classes describing a third-party API request, which will use HTTP as transport layer but in my app the responsibility is Guzzle/curl. These classes are in no way related to my app controllers, requests, resources, middleware or the apps HTTP kernel. Mixing them will only lead to trouble, misconceptions and a lot of brain hacking if you talk about app HTTP requests.

An alternative would be App\Transporter - it won't conflict with other packages (package name as namespace) and makes it clear that the classes inside are something totally custom.

Hey @JustSteveKing!

Love this package :)

This isn't really an issue, but I have an API where I need to send XML for some requests and was hoping to use this package, so I created this trait that I thought might be worth sharing:

<?php

namespace App\Transporter;

use Illuminate\Http\Client\Response;

trait SendsXml
{
    public function withXml(string $xml): static
    {
        $this->request
            ->withHeaders(['Accept' => 'application/xml'])
            ->withBody($xml, 'application/xml');

        return $this;
    }

    public function send(): Response
    {
        return $this->request->send(
            $this->method,
            $this->getUrl()
        );
    }
}

I don't think it quite handles all of the use cases Transporter is designed for, but for my case it worked a treat.

The usage in the request then looks something like this:

<?php

declare(strict_types=1);

namespace App\Transporter\Requests;

use App\Transporter\SendsXml;
use JustSteveKing\Transporter\Request;

class MyXmlRequest extends Request
{
    use SendsXml;

    protected string $method = 'POST';

    protected string $path = '/my-endpoint';
}

And then using the request looks something like this:

MyXmlRequest::build()->withXml($xml)->send();

Feel free to do whatever you like with it and to close this issue whenever you like.

If descendants don't specify $this->path, then calling path() will fail with an error: Typed property JustSteveKing\Transporter\Request::$path must not be accessed before initialization

This is one way to resolve the problem. Another option is to initialize the variable when it's declared:

    protected string $path = '';

Not sure which way is best/preferable...or if there's some other even better way to go. 🤓

Hey Steve,

When utilising transporter within an API, I receive a server error, but when called manually it works without any issues.

CraftheadRequest

abstract class CraftheadRequest extends Request
{
    protected string $method = 'GET';
    protected string $baseUrl = 'https://crafthead.net/';
}

Then, my main request that extends..

class NameToUUIDRequest extends CraftheadRequest
{
    public function username(string $username)
    {
        $this->setPath("profile/{$username}");

        return $this;
    }
}

And use it, like so..

        $response = NameToUUIDRequest::build()->username($username)->send();

        if ($response->failed()) {
            return null;
        }

        return $response->json('id');

Any reason for this? I considered it may be the user agent, but tried it and same thing, and even manually tried API without agent and worked.

Tried to call this method as the readme says, but it is not found (withToken())

MyRequest::build()->withToken($token)->send()

Im dealing with an API where i need a new token every transaction, so I need to call the authenticate api first, get the token then call the transaction API each time

Issue Reference

#11

PR Documentation

• Added feature to run concurrent request.
• Code refactor.
• Updated README.md with concurrency example.

How to test

Run test cases.

P.S. : it would be cool if you add hacktoberfest to the repo's topics.

I believe that the local baseUrl setting, if set, should be preferred over any global value that might be set via configuration file.

Before this change, if someone wants to use the config setting and some one-off local settings, then for each of the one-off instance, setBaseUrl() will have to be called explicitly.

After this change, someone can set the config setting and know that it will be used everywhere except for those one-off instances where it is set locally. There is no longer any need to call setBaseUrl() explicitly.

Please let me know if you have any questions/concerns.

This PR adds basic support for remembering request responses. I often need to implement it myself when dealing with 3rd party APIs, and I thought it would be nice to have this built in.

SomeRequest::build()->remember(now()->addMinute());

This could be further improved by adding configurable properties to the Request class, but I wanted to keep it simple, at least for now. I also wanted to inject the cache manager to Request, but I think this could be a breaking change, so I opted for using service locator via the cache() helper instead.

This PR adds a convenient $throws property to JustSteveKing\Transporter\Request to avoid having to call ->throw after each ->send call.

Currently, I have the following in all my base Request classes:

public function send(): Response
{
    return parent::send()->throw();
}

After this PR, I may simply override the $throws property and set it to true.

I also updated the development dependencies, otherwise I couldn't use Http::fake in the tests.

Hello, @JustSteveKing thank you for this great package once again and also for the quick fixes from yesterday. I was thinking about some ways you could improve the package. Below is an example:

I'm working on an app that consumes solely on an API developed in Laravel, now for crud operations like Post management, I would have to create a Transport Request class for all the crud operations which is how the current package works (I stand to be corrected). I would have wished to just create one class e.g UpsertPosts or PostTransporter which will take care of all the crud operations instead of creating different classes for Create, Read, Update and Delete.

In the end, I would love to be able to do something like this:

<?php

namespace App\Http\Controllers;

$post = PostTransporter::build()
->method('Post') or ->post (making it possible to overwrite the method via this constructor
->send();

Also instead of adding ->withData(['title' => $request->title]), I would like to be able to pass the data instead inside the PostTransporter class to keep things clean maybe via the constructor like so:

<?php

declare(strict_types=1);

namespace App\Transporter\Requests\Sour\Posts;

use JustSteveKing\Transporter\Request;
use App\Http\Requests\UpsertPostRequest;

class Post extends Request
{
    protected string $method = 'GET';
    protected string $path = '/v1/post/{id}';


    public function __construct(UpsertPostRequest $request) {
        'title' => $request->id,
        'description' => $request->description,
        'release_date' => $request->release_date,
    }

    public function rules(): array
    {
        return [
            'title' => 'required',
            'description' => 'required',
            'release_date' => 'required',
            'rating' => 'required',
            'ticket_price' => 'required',
            'country' => 'required',
            'genre' => 'required',
            'photo' => 'required',
        ];
    }
}

NB: So one can define the validation rule via the function above or just import their validation request as I did in the construct

I hope I was able to explain myself well. This would have been super amazing to have. Once again thanks for all the hard work.

How can I implement SendsXml using Concurrently?

class AdequateShopRequest extends Request
{
    use SendsXml;
    protected string $method = 'POST';
    protected string $baseUrl = 'https://webservice.com';
    protected array $data = [];
}


$responses = Concurrently::build()->setRequests([
        AdequateShopRequest::build()->setPath('/something')->withXml($xml_body),
])->run();

Error: Typed property JustSteveKing\Transporter\Request::$request must not be accessed before initialization ../vendor/juststeveking/laravel-transporter/src/Concerns/SendsXml.php:17

Or if there is a way to set the contentType as property and just pass the body, something like this:

class AdequateShopRequest extends Request
{
    protected string $method = 'POST';
    protected string $baseUrl = 'https://webservice.com';
    protected string $contentType = 'application/xml';
}

$responses = Concurrently::build()->setRequests([
        AdequateShopRequest::build()->setPath('/something')->setBody($xml_body),
])->run();