Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Another method to call requests from connectors? #46

Closed
Sammyjo20 opened this issue Mar 4, 2022 · 3 comments
Closed

Another method to call requests from connectors? #46

Sammyjo20 opened this issue Mar 4, 2022 · 3 comments
Labels
enhancement New feature or request

Comments

@Sammyjo20
Copy link
Member

Sammyjo20 commented Mar 4, 2022

Saloon has given people the option to make requests by calling the request class or using the connector by specifying requests in the $requests property on the connector, but I was thinking of another one:

$connector = new ForgeConnector();

$connector->request(new GetServersRequest); // Init the request but don't send it

$connector->send(new GetServersRequest); // Send the request right away

This gives people the ability to define defaults on the connector while not having to register their request and also get
type-hinting in their IDE.

@Sammyjo20 Sammyjo20 added the enhancement New feature or request label Mar 4, 2022
@Sammyjo20
Copy link
Member Author

Maybe this should be treated the new "first party" way of sending requests? It allows you to define default data in your constructor like an API token, without needing a keychain.

@WalrusSoup
Copy link
Contributor

I think this is ok, but i don't think it's ultimately necessary.

I do see how this is getting a bit complicated, and in the end if kinda feels like code is being moved around and just shifted from place to place. After really, really thinking about it, i think the plugin approach is most straight forward and should probably just be titled as the official way to do authorization.

I made an example repo here of how it can be done. The only thing is that it needs a static helper. Given how class based Saloon is I believed that it was possible to keep the same 'cool' syntax approach, but after thinking about it, this solution is the most straight forward, has the least amount of code, and feels like the most compatible for everyone.

Having the token be able to be set on the request possibly felt like it was inconsistent since, typically, authorization headers are sent on all requests which made it feel more appropriate to be in the connector. But i can see a use case for both.

Maybe the final solution for this is just more documentation on the various approaches? But I think that settling on a "best practice is to put it in a plugin" will help portability a lot, then anyone using Saloon will know where authorization will be living without everyone doing their own approach.

I put an example repo here with a test located here

@Sammyjo20
Copy link
Member Author

Hey, thanks for putting this together - that's super helpful so I appreciate it 🤘 I agree. I want to streamline how Saloon works to make it simpler to use. At the end of the day Saloon was born because configuring Guzzle caused a lot of thinking.

My main concern is that people will put something in the constructor of the connector and then when Saloon tries to boot up the connector, it fails because a specific argument is required. Currently this is worked around by doing the following:

Request::make()->setConnector(new MyConnector)->send();

I'm going to really think over how I'm going to handle authentication. I think I might change the wording from "keychain" to "credentials" or something a bit more descriptive, then if people choose to, they can create a Saloon Credential class that is just like you have in your example, however it's slightly simpler because people won't have to define their own plugin for it.

With all of this, the idea is that it is optional if people choose to.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants