Repository navigation
Allow to set global defaults for ApiResource attributes and other options #3099
Description
It would be nice to configure global defaults for all class marked with @ApiResource (or configured in YAML/XML etc).
It could be a new config section such as the following:
api_platform:
defaults:
attributes: # ...
item_operations: # ...
collection_operations: # ...
normalization_context: # ...
graphql: # ...
# ...
# All properties defined in https://github.com/api-platform/core/blob/master/src/Annotation/ApiResource.php should be configurableFor instance, it would allow to make the API globally read only:
api_platform:
defaults:
itemOperations: ["get"]
collectionOperations: ["get"]Other example, enable Mercure for all resource:
api_platform:
defaults:
mercure: trueOr always use Messenger:
api_platform:
defaults:
messenger: trueImplementing this feature should be trivial:
- add the new config option in https://github.com/api-platform/core/blob/master/src/Bridge/Symfony/Bundle/DependencyInjection/Configuration.php
- Add a new
ResourceMetadataFactory, with a low priority, applying the defaults if not set
Most options are stored in metadata's attributes, some other are top level metadata properties (itemCollections and collectionOperations and graphql AFAIR). Basically, the content of defaults should be passed as-is to resources' attributes, except the special one previously mentioned.
Existing configuration option for resource attributes (pagination, cache headers...) should probably be deprecated for consistency.
Activity
[-]Allow to set global defaults for ApiResource attribues and other options[/-][+]Allow to set global defaults for ApiResource attributes and other options[/+]teohhanhui commentedon Sep 30, 2019
I don't think we need this. It'll make things very confusing...
xavren commentedon Sep 30, 2019
Could be nice to configure defaults operations to protect by default all
@ApiResourcethis could be very usefull i thinkjulienfalque commentedon Dec 12, 2019
Is there anything left to do to implement this after #3151?
soyuka commentedon Dec 17, 2019
Indeed this should be fixed by #3151
teohhanhui commentedon Dec 17, 2019
I remember @dunglas discovered an issue with
cache_headers.