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
Create an interface to resolve the operations path #666
Conversation
$routeCollection->get('api_dummies_get_item'), | ||
$this->getRoute('/dummies/{id}.{_format}', 'api_platform.action.get_item', DummyEntity::class, 'get', ['GET']) | ||
$this->getRoute('/dummies/{id}.{_format}', 'api_platform.action.get_item', DummyEntity::class, 'get', ['GET']), | ||
$routeCollection->get('api_dummies_get_item') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did this because the expected value must be before the one tested.
ping @api-platform/core-team |
LGTM |
Dirty for the delay, I prefer to review it in depth or have the opinion of another member of the core team before merging it. |
@theofidry reacted to @Simperfit comment, i guess that means he agrees ? |
@@ -35,12 +35,7 @@ public function getConfigTreeBuilder() | |||
->scalarNode('title')->defaultValue('')->info('The title of the API.')->end() | |||
->scalarNode('description')->defaultValue('')->info('The description of the API.')->end() | |||
->scalarNode('version')->defaultValue('0.0.0')->info('The version of the API.')->end() | |||
->arrayNode('naming') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we need to update the doc accordingly as well
👍 from me but I would be more confortable if @teohhanhui or @dunglas have time for a deeper review :) |
@@ -13,7 +13,7 @@ | |||
<argument type="service" id="api_platform.metadata.property.metadata_factory" /> | |||
<argument type="service" id="api_platform.resource_class_resolver" /> | |||
<argument type="service" id="api_platform.operation_method_resolver" /> | |||
<argument type="service" id="api_platform.iri_converter" /> | |||
<argument type="service" id="api_platform.path_resolver.operation" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't the service be named api_platform.operation_path_resolver
for consistency with other services?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes indeed, good point 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you update the PR? I'll merge it after that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
I've just reviewed it in deep. Smart design! I've just a minor comment regarding the service name. WDYT @Ener-Getick? |
Thanks ! And i updated the services name :) |
Test are broken now. |
Oops i forgot to change a service name in the tests... |
Thank you @Ener-Getick! |
@Ener-Getick do you think you'll be able to also update the related docs? https://github.com/api-platform/docs/blob/master/core/path-naming-strategy.md |
@dunglas yes it shouldn't be too long. I'll do that asap ;) |
Thanks! |
I don't like the name |
I like |
The advantage of |
Maybe something relating to metadata? |
@Ener-Getick:
|
Ok I've misunderstood... |
|
<argument type="service" id="api_platform.operation_path_resolver.custom" /> | ||
</service> | ||
|
||
<service id="api_platform.operation_path_resolver.custom" class="ApiPlatform\Core\PathResolver\CustomOperationPathResolver" public="false"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't api_platform.operation_path_resolver.custom
decorate api_platform.operation_path_resolver.default
?
(Why do we need the "default" part of the name, in the first place? This was already discussed before in #547)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be weird to decorate a service defined by the user in case he uses its own path resolver, don't you think ?
About the default
part, that's just an alias and i couldnt use .operation_path_resolver
as it is already in use. Maybe a better name would be .fallback
or .root
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to be clear about the decoration priority, but by not using Symfony DI's service decoration (when in fact it's exactly what you're trying to achieve), the current implementation is clearly inflexible.
It would be weird to decorate a service defined by the user in case he uses its own path resolver, don't you think ?
I'll address this separately.
Create an interface to resolve the operations path
This PR solves an issue of the swagger
DocumentationNormalizer
which doesn't include resources if they don't have at least one collection operation (that's the case when a resource has only item operations).I finally choose a different solution than the one I proposed in #648 (comment) and created a new interface
OperationPathResolverInterface
. It replaces the currentResourcePathNamingStrategyInterface
.