This PR introduces a new listener which can be subscribed to so that it records requests in Laravel Telescope. The telescope entry will be recorded under the "HTTP Client" section of Telescope.

Fixes #21

Is it possible in saloon-laravel override bootConnector method so its resolve dependency from laravel service container?

Problem is when writing tests cannot manage to mock it because of this line: https://github.com/Sammyjo20/Saloon/blob/v1/src/Http/SaloonRequest.php#L110

$this->setConnector(new $this->connector);

should be easy fix (not tested)

$this->setConnector(resolve($this->connector::class));

I did a hacky workaround by overriding getConnector() so I can dependency injection my FetchifyConnector to FetchifyUKPostcodeLookupRequest https://github.com/Sammyjo20/Saloon/blob/v1/src/Http/SaloonRequest.php#L120

<?php

declare(strict_types=1);

namespace App\Http\Saloon\Requests\Fetchify;

use App\Http\Saloon\Connectors\Fetchify\FetchifyConnector;
use App\Http\Saloon\Responses\Fetchify\FetchifyUKPostcodeLookupResponse;
use App\Libraries\Helpers\LaravelGlobals;
use Sammyjo20\Saloon\Constants\Saloon;
use Sammyjo20\Saloon\Http\SaloonRequest;
use Sammyjo20\Saloon\Http\SaloonConnector;

class FetchifyUKPostcodeLookupRequest extends SaloonRequest
{
    /**
     * Define the method that the request will use.
     *
     * @var string|null
     */
    protected ?string $method = Saloon::GET;

    /**
     * Define a custom response that the request will return.
     *
     * @var string|null
     */
    protected ?string $response = FetchifyUKPostcodeLookupResponse::class;
    private string $postcode;

    public function __construct(
        private readonly FetchifyConnector              $fetchifyConnector,
        private readonly LaravelGlobals                 $laravelGlobals,
    ) {

    }

    /**
     * Need to set like this to get it working with dependency injection
     *
     * @return SaloonConnector
     */
    public function getConnector(): SaloonConnector
    {
        return $this->fetchifyConnector;
    }

    /**
     * @link https://fetchify.com/docs/json-api/uk-postcode-lookup.html#full-address-rapidaddress
     * @return array
     */
    public function defaultQuery(): array
    {
        return [
            'key' => $this->laravelGlobals->config('services.fetchify.key'),
            'include_geocode' => false,
        ];
    }
}

<?php

declare(strict_types=1);

namespace App\Http\Saloon\Connectors\Fetchify;

use App\Libraries\Helpers\LaravelGlobals;
use Sammyjo20\Saloon\Http\SaloonConnector;
use Sammyjo20\Saloon\Traits\Plugins\AcceptsJson;

class FetchifyConnector extends SaloonConnector
{
    use AcceptsJson;

    public function __construct(private LaravelGlobals $laravelGlobals)
    {
    }

    /**
     * Define the base url of the api.
     * @link https://fetchify.com/docs/json-api/uk-postcode-lookup.html#full-address-rapidaddress
     * @return string
     */
    public function defineBaseUrl(): string
    {
        return $this->laravelGlobals->config('services.fetchify.endpoint');
    }
}

Hope you got the point, cheers.

Would close #3. However, this is not as trivial as I previously thought. @Sammyjo20 do you know any way how I could get the full namespace and class name of the newly generated response?

I assumed that the \Sammyjo20\Saloon\Http\SaloonRequest::getFullRequestUrl method returns, well, the full request URL. Fr me this includes the query params as well.

How can I retrieve the full URL used for the request from the response? 🤔 Using $request->getQuery() doesn't 100% feel right/reliable as theoretically the return value could change between running the request and asking for the used query string.

Related to https://github.com/Sammyjo20/Saloon/issues/11.

I think we should add a command php artisan saloon:response and also a flag to pa saloon:request SomeRequest -r SomeResponse which already prefills the request.

What do you think about it?

Currently the cli commands generate requests, responses and connectors in separate folders. However, when writing multiple API integrations it becomes messy when these three from different applications become mixed up. Therefore I propose an refined command line experience consisting of the following:

1. I like the location in the Http folder as it deals with outgoing Http requests. I don't like the name Saloon for that folder. I suppose it is for branding purposes but I don't think that it is the right way forward because it doesn't clearly convey the purpose of the directory. I think it should be named something like Integration.
2. Furthermore I fear that different integrations become mixed up in a context with multiple integrations. Therefore I think it should contain multiple directories with the current structure in them (but the Connectors directory omitted as there is only one connector per API I suppose).

app/
├─ Http/
│  ├─ Integration/
│  │  ├─ Integration1/
│  │  │  ├─ Requests/
│  │  │  ├─ Responses/
│  │  │  ├─ Integration1Connector.php
│  │  ├─ Integration2/
│  │  │  ├─ Requests/
│  │  │  ├─ Responses/
│  │  │  ├─ Integration2Connector.php

3. Number 2 would also lead to an additional flag called something like -i|--integration to specify which integration is intended to have an addition.

What do you think about it?

I'd be willing to contribute this addition.

Hello guys,

thank you for this wonderful package.

I am developing a connector for Google OAuth.

Google provides three completely different Base URL's for Authorization, Token and User.

My plan was to define each complete URL as an Endpoint in the OAuthConfig and leave the BaseUrl empty.

Doing so results in a request URL that always starts with an '/' in the beginning which makes the curl fail.

For example:

$connector->getAuthorizationUrl() // => /https://accounts.google.com/o/...

Same is true for The Token & User Endpoint.

Now I know I could create 3 different connectors for each endpoint and provide a non empty BaseURL and the Endpoint but then I would have 3 files instead of one and it kinda fails the purpose of this flow in my opinion.

I think it's an easy fix to skip the beginning '/' if the BaseUrl is empty.

class YoutubeOAuthConnector extends SaloonConnector
{
    use AuthorizationCodeGrant;

    public function defineBaseUrl(): string
    {
        return '';
    }

    protected function defaultOauthConfig(): OAuthConfig
    {
        return OAuthConfig::make()
            ->setClientId(config('youtube.api.client_id'))
            ->setClientSecret(config('youtube.api.client_secret'))
            ->setDefaultScopes(config('youtube.api.scopes'))
            ->setAuthorizeEndpoint('https://accounts.google.com/o/oauth2/v2/auth?access_type=offline&prompt=consent')
            ->setTokenEndpoint('https://oauth2.googleapis.com/token')
            ->setUserEndpoint('https://www.googleapis.com/oauth2/v3/userinfo')
            ->setRedirectUri(route(config('youtube.api.redirect_uri')));
    }
}

It would be cool to group requests by any meaning - for example the primary entity. That way the method names would be shorter. A real problem I see with that is the missing autocompletion. Right now you can at least add @method AllMoviesRequest allMoviesRequest() doc-block. That's not possible anymore as I only can annotate the ->movies property but not the methods available on it.

$requests = [
    'movies' => [
        'all' => AllMoviesRequest::class,
    ],
];

$sdk->movies->all()->send()->json();

I assume that it would be added to the core with a new class Proxy (tbd) which retrieves an instance of the connector and the array of method to requests mappings. Benefit: this could be easily enhanced to a multi-level thing like GitHub API for example $github->user->repo->show($username, $reponame) As it would just pen another instance of that proxy.

With Laravel HTTP client you can record responses from real requests. This is useful to generate an initial fixture set for your tests and don't have to create them manually. In the best case Saloon would work the same - so it would switch to a partial mocking approach and record every mocked and real response. Possibly with an isMocked = true flag but not important. That way you could list unmocked requests somewhere and automatically create fixtures to make them mocked in the next run or whatever you want but don't break/fail the execution.

In Laravel it's part of the partial HTTP client mocking approach. As soon as you call Http::fake() it will record every request/response.

• \Illuminate\Http\Client\Factory::record
• \Illuminate\Http\Client\Factory::recorded

Below an example from TMDB test code:

protected function tearDown(): void
{
    foreach (Http::recorded() as $record) {
        /**
         * @var \Illuminate\Http\Client\Request $request
         * @var \Illuminate\Http\Client\Response $response
         */
        [$request, $response] = $record;

        if ($response->successful()) {
            $filepath = $this->fixturePath(
                Str::after(parse_url($request->url(), PHP_URL_PATH), '/3/'),
                parse_url($request->url(), PHP_URL_QUERY)
            );

            File::ensureDirectoryExists(dirname($filepath));
            File::put(
                $filepath,
                json_encode($response->json(), JSON_PRETTY_PRINT | JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES)
            );
        }
    }

    parent::tearDown();
}

With Laravel HTTP client you can mock responses from a Closure. This is super useful for larger fixture sets following a simple URL to path transformation. Would be great if that would be possible with Saloon too - as it's not a real option to create thousands of mock responses and URL patterns from a list of fixture files.

Below an example from TMDB test code:

Http::fake([
    'https://api.themoviedb.org/3/*' => function (Request $request): PromiseInterface {
        try {
            $body = $this->fixture(
                Str::after(parse_url($request->url(), PHP_URL_PATH), '/3/'),
                parse_url($request->url(), PHP_URL_QUERY)
            );
        } catch (FileNotFoundException $e) {
            return Http::response([
                'error' => [
                    'message' => $e->getMessage(),
                    'trace' => $e->getTraceAsString(),
                ],
            ], Response::HTTP_NOT_FOUND);
        }

        return Http::response($body, Response::HTTP_OK);
    },
]);

• Fixing tests
• Fixing stubs
• Fixed stub
• Working with the latest v2.x branch
• Updated stubs
• Cleaned up the HttpSender
• Swap back to GuzzleSender for stability
• Fixed other tests

In Laravel you have access to TestResponse if you call one of your own endpoints in a test case. This response gives you access to a ton of assertions - headers, status, JSON and with packages even HTML...

How about reusing this class or creating a custom one for requests in tests? 🤔

$connector->user()->get($id)
  ->assertStatus(200)
  ->assertHeader('x-header', 'foobar')
  ->assertJson(fun(AssertableJson) => ...);

Hi, first thanks for the nice package, but as always it's still room to improve it.

Laravel telescope has a really nice feature HTTP Client watcher records outgoing HTTP client requests made by your application.

Is it plan to send requests / responses to laravel telescope?