Вложенные параметры / значения в запросах POST
Я думал о хорошем способе обработки вложенных / сложных значений в запросах POST к ресурсу apigility.
Например, заказ может содержать набор элементов заказа в одном запросе POST, который используется для создания заказа. И заказ, и позиция заказа существуют как ресурс. Однако мне бы очень хотелось иметь только один запрос, который бы создавал объекты заказа и позиции заказа. Обработка этого ресурса не является проблемой, но мне интересно, как бы вы сконфигурировали этот ресурс (давайте назовем его order-place) с помощью пользовательского интерфейса apigiliy — или, если вообще невозможно, с помощью конфигурации. Применение валидаторов и фильтров — одна из ключевых особенностей apigility, и я хотел бы продолжать использовать это, даже для сложных запросов данных.
И прежде чем вы спросите, использование подчеркивания для разделения значений областей, например, order_comment и order_item_comment не должно быть опцией.
Есть идеи?:)
Дополнение: пример полезной нагрузки json-запроса может выглядеть так:
{
"created_at": "2000-01-01",
"amount" : "5000.00",
"address" : {
"name": "some name",
"street": "some street"...
},
"items" : [
{"productId":99,"qty":1}
...
]
}
Решение
Если вы используете ContentValidation Затем вы можете настроить входной фильтр для вложенных ресурсов, назначив его переменной. Затем вы должны добавить ключ типа (необходимо, иначе повторное использование фильтра не будет работать). Теперь вы можете использовать эту переменную в своем input_filter_specs и вы можете повторно использовать весь фильтр внутри другого фильтра. Так что-то вроде этого в вашем config.php:
<?php
namespace Application;
// Your address config as if it was used independently
$addressInputFilter => array(
'name' => array(
'name' => 'name',
'required' => true,
'filters' => array(
//...
)
'validators' => array(
//...
)
),
'street' => array(
'name' => 'street',
'required' => true,
'filters' => array(
//...
)
'validators' => array(
//...
)
),
// 'type' key necessary for reusing this input filter in other configs
'type' => 'Zend\InputFilter\InputFilter'
),'input_filter_specs' => array(
// The key for your address if you also want to be able to use it independently
'Application\InputFilter\Address'=> $addressInputFilter,
// The key and config for your other resource containing a nested address
'Application\InputFilter\ItemContainingAddress'=> array(
'address' => $addressInputFilter,
'amount' => array(
'name' => 'amount',
'required' => true,
'filters' => array(
//...
),
'validators' => array(
//...
)
)
//... your other fields
)
)
Другие решения
Исходя из ответа Уилта, я обнаружил, что следующий код также работает:
# file path: /module/MyApi/config/module.config.php
// some other stuff
'MyApi\\V1\\Rest\\MyRestService\\Validator' => array(
'address' => array(
0 => array(
'name' => 'name',
'required' => true,
'filters' => array(),
'validators' => array(),
),
1 => array(
'name' => 'street',
'required' => true,
'filters' => array(),
'validators' => array(),
),
'type' => 'Zend\InputFilter\InputFilter'
),
'amount' => array(
'name' => 'amount',
'required' => true,
'filters' => array(),
'validators' => array()
)
Единственная проблема, которую я получаю, это когда address передается как поле (строковое или числовое), а не как массив или объект. В этом случае Apigility выдает исключение:
Zend \ InputFilter \ Exception \ InvalidArgumentException: Zend \ InputFilter \ BaseInputFilter :: setData ожидает массив или аргумент Traversable; полученная строка в /var/www/api/vendor/zendframework/zendframework/library/Zend/InputFilter/BaseInputFilter.php в строке 175
Добавление address как дальнейшее простое (обязательное) поле избегает исключения, но тогда Apigility не видит никакой разницы, передаем ли мы address как массив name а также street или фиктивная строка.
detector