Skip to content

Api Platform

Configuring Resource Configuration location

You need to set the following in config/packages/api_platform.yaml:

YAML or XML

api_platform:
    mapping:
        paths: ['%kernel.project_dir%/config/api_platform']

Annotations

Standard

api_platform:
    mapping:
        paths: ['%kernel.project_dir%/src/Entity']

Using Doctrine Static Meta

api_platform:
    mapping:
        paths: ['%kernel.project_dir%/src/Entities']

Keeping config in one place

It is possible to keep your project specific config in one file that can then be tracked in git

This is done by adding the following lines to the config/packages/api_platform.yaml file

mapping:
    paths:
      - '%kernel.project_dir%/src/api_resources.yaml'

You can then use this file to configure your entities.

This will override the configuration above, so you need to tell API Platform where your entities are. This can be done with the following lines

resource_class_directories:
    paths: '%kernel.project_dir%/src/Entities'

Restricting read or write access to certain properties

You want certain fields to be read only, or even not be displayed in the API at all.

Using the src/api_resources.yaml file above add the following lines

resources:
    App\Entities\Example:
        description: 'Details about individual suppliers'
        iri: 'http://schema.org/Organization'
        attributes:
            normalization_context:
                groups:
                    - read
            denormalization_context:
                groups:
                    - write

This means that you have to specify which properties can be read, and which ones can be written.

To do this you need to create a file in the api/config/serialization directory - the best options is to name it after the class and add the following

App\Entities\Example:
    attributes:
        name:
            groups: [read, write]
        readOnlyAttribute:
            groups: [read]

Operations (sort of like Controllers)

From the docs:

"API Platform Core relies on the concept of operations. Operations can be applied to a resource exposed by the API. From an implementation point of view, an operation is a link between a resource, a route and its related controller."

Subresources

From the docs:

"A subresource is a collection or an item that belongs to another resource. The starting point of a subresource must be a relation on an existing resource."

Custom Operations and Controllers

Controlling Available Fields