Блог

Я пытаюсь создать метод API для пользовательских структур данных, который мог бы работать с отношениями к другим ресурсам API, но имеет проблемы с normalize_input обработчиками групп действий. Например, мне нужно обработать список orderlineitems элементов и дать пользовательский ответ. Чтобы подойти к этой задаче, я создал класс модели требуемой структуры.

 class ListModel
{
   /** @var Collection|OrderLineItem[] */
   protected $lineItems;
   ...
}
 

И зарегистрировал его в api_frontend.yml :

 api:
  entities:
    ArdexBundleOrderBundleApiModelCartProducts:
      disable_meta_properties: true
      fields:
        lineItems:
          target_class: OroBundleProductBundleEntityProduct
          target_type: to-many
        actions:
          get: false
          get_list: false
          update: false
          delete: false
          delete_list: false
          create: true
 

С помощью Xdebug я обнаружил, что все данные запроса должны отправляться в meta параметре, и в этом случае included часть тела запроса игнорируется.

Из приведенной выше информации следует, что платформа API не знает, как работать с моделью CartProducts и что делать со списком элементов строк. Потому что CartProducts не является сущностью, и у ресурса даже нет идентификатора.

Чтобы это сработало, вы должны явно сопоставить данные в пользовательском процессоре API для выполнения create действия. Видеть:

• Создание процессора API
• Создайте сведения о реализации действия.

Но я все еще не уверен, что для этой задачи неплохо использовать полнофункциональный API-фреймворк. Если вы не собираетесь использовать какие-либо другие действия, кроме создания, и ресурс API полностью настраиваемый, возможно, лучше создать пользовательский контроллер API и явно управлять его сложностью.

Из того, что у нас есть в core в качестве примеров, вы можете проверить productcollection ресурс, но он доступен только для чтения. Нет примеров, когда модель ссылается на сущность, и платформа API не может знать, как с ней работать.