feat: add the ability to create API routes with multiple route parameters

[jonerickson]

This PR aims to one, add a new feature, while two, allow more use cases for this package. Currently, when defining resources, if the route has another route parameter included, the package will not resolve the correct route parameter within the controller function definitions. Currently they are hardcoded to not allow more route parameters.

The current user story I am trying to fix with this PR is to define API routes like such: https://xxxxxx.com/api/{apiVersion}/users/{id}.

We want our end users to be able to specify the API version using a route parameter. Within our application, we look at apiVersion and determine which HTTP resource to return to them.

In the current state of the package, within the HandlesStandardOperations::show($request, $key) method, $key will resolve to, in our user story, v1, instead of the User ID.

To fix this, we have introduced a backwards compatible key resolver that changes the function definition to HandlesStandardOperations::show($request, ...$args) to allow multiple route parameters to be resolved. Within a bound KeyResolver class in the container, some simple logic is done to return which parameter should be used as the $key for the further operations.

If a user needs to customize the KeyResolver, they simply bind a new instance of their own custom implementation. I have included tests to illustrate.

[jonerickson]

This PR is ready for review. There were two test case fails. One a seg fault, and the other a unique constraint violation. Both edge cases. I am confident if they were rerun they would pass. Thanks,

[alexzarbn]

Hi @jonerickson,

Thank you for the PR!

I wonder if it would be possible to make the KeyResolver work with parameter names rather than indices?

[jonerickson]

Great suggestion. Will update the PR!

[jonerickson]

Hey @alexzarbn, after mulling this over, I am not coming up with any solution other than what I suggested. Using an out-of-the-box implementation of this package, using the show endpoint as an example, we always know that the first argument in the method will be the key to resolve.

As users implement this package, we have no way of knowing what the parameter name is they want to use in the show endpoint to resolve correctly. We can obviously see all the parameters in the current route being requested, but we do not know which one the user wants to resolve as the show ID. Hence allowing the user to bind their own implementation of the key resolver.

In my case where I have all my routes as (using show as an example) .../{apiVersion}/users/{id}....I always know my key to be resolved will be the second parameter. And each parameter name will be different for each resource I am writing a route for.

Does this make sense? Can you think of another way to do it?

[jonerickson]

Hey @alexzarbn any second thoughts on this? I have been using my fork of this feature in prod and it has worked great.

[alexzarbn]

Hi @jonerickson,

Sorry for the late response - past few months were quite hectic.

Okay, that makes sense, thank you for looking into it! Merging ~