Level 80
@gerardnll You can’t change method-logic injection like that.
If you want to read how Stripe actually versions their API, then you can read the blog post they published on the topic: https://stripe.com/blog/api-versioning
Jan 19, 2022
4
Level 1
Versioning of Request classes
I have an API, and currently it is on the V1. Major changes to routes, for example, may provoke a change in the API major version number, but this is not the case now.
What I want is, to do as Stripe does, use a date to also define API versions, for example '2022-01-01'. Normally, this version changes affect responses and requests to the API. In this case I want to change my Request class depending on the received API Version (or use a default).
I would like to know how I can do something like this:
Controller:
public function update(UpdateReviewGatheringRequestContract $request, Review $review): ReviewResource
{
// Update review
}
So i have various request files, that handle the request differently but all extend that contract (and FormRequest).
App\Http\Requests\V1\V20210701\UpdateReviewGatheringRequest App\Http\Requests\V1\V20220101\UpdateReviewGatheringRequest
Thanks
Level 1
@martinbean AFAIK they talk about responses, barely about changes in the request.
I've seen I can put some logic into a provider that determines the request object that is resolved taking in account the version provided in the request, but I'm still thinking about the cleanest solution.
Level 80
@gerardnll The “cleanest” solution is to not try and shoe-horn handling of multiple versions in one location. No matter what you do, you’re going to have conditions.
Instead, have different controllers for the different versions of the API, that make use of different form request classes. This way, each class has a single responsibility instead of trying to come up with “clever” solutions.
Level 1
@martinbean Ok, here's the situation so we can talk about the real case. A request property called 'tags', has a validation rule that checks for the existence of the value in the db (Rule::exists('tags', 'ref')). On a new 'version' of the API, this check has to also make sure a certain column is null (Rule::exists('tags', 'ref')->whereNotNull('tag_id')). There's no other change in any other file, how do I handle this case without having to make new controllers, which I think may be too much now and I don't want to increase the API value to V2, i wanted to do like a 'revision' like 2022-01-01 as Stripe does.
Please or to participate in this conversation.