Они все единого формата, т.е. на них у клиентов универсальный обработчик, соответственно и в документации такое не описываем.
А если все же на основе какой-то ошибки нужно построить логику – то этот момент пойдет уже в другой тип документации, в которой текстом описано как работать с методами и решать задачи.
Эти классы описывают входные и выходные параметры action'ов
Все верно, реквест модели выглядят примерно вот так:
Пример
<?php
namespace App\AcmeBundle\RequestModel;
use RestApiBundle\Annotation\RequestModel as Mapper;
use Symfony\Component\Validator\Constraints as Assert;
use RestApiBundle\RequestModelInterface;
class CreateMovie implements RequestModelInterface
{
/**
* @var string
*
* @Mapper\StringType()
* @Assert\Length(min=3)
*/
private $name;
/**
* @var string[]|null
*
* @Mapper\CollectionType(type=@Mapper\StringType(), nullable=true)
*/
private $genres;
... getters and setters
}
А как вы, в таком случае, будете обрабатывать ошибочные случаи
Ошибок есть всего грубо говоря 3 вида:
1) Ошибки валидации/маппинга реквест модели – это бандл обработает сам и вернет клиенту ошибку, т.е. внутри action доступна уже чистая модель
2) Уникальные ошибки – это ошибки с каким-то своим поведением, например 404, 403 и тд, они отлавливаются и отдается json response вместо них + статус
3) Ошибки бизнес логики – это ошибки которые нужно показать пользователю, они тоже делаются через эксепшены, одна ошибка – один класс. Внутри каждого эксепшена можно указать константу для перевода, либо покажется дефолтный текст.
Проблема очень знакома, пишем долгое время документацию вручную, времени съедает много, часто случается что забыли что-то обновить, в общем не рабочее решение.
Сейчас разрабатываю rest-api-bundle для Symfony и тоже хочу реализовать там автогенерацию документации swagger. Но я пошёл другим путем, запросы и ответы в бандле описываются в виде классов, а уже по этим классам будет генерироваться json схема.
Если использовать реквести/респонс модели – можно на их основе генерировать json-схемы + добавив сюда пару анотаций с названием метода/описанием – можно сделать полноценную генерацию документации
Возможно я чего-то не понимаю, или этот подход не для меня, поэтому ответьте пожалуйста на вопрос:
Сейчас, грубо говоря, мы подгоняем хранение данных под то, как они будут использоваться. Т.е. данные в базах могут быть специально нормализованы под какой-то высоконагруженный endpoint и от этого будет профит. Но ведь получается сам подход GraphQL этому противоречит? А как с таким подходом борются с нагрузками?
Думал увидеть какую-то общую статью, где бы говорили про версионность, обратную совместимость и прочие проблемы и тд. А по факту получил рассказал про то, как плохо подошли к этому в вашей компании
Если задачу решить через трансформеры, то это будет так же «в двух местах», только при этом в двух совсем разных местах. А в случае автора, если он использует аннотации, то «валидация» хоть и будет два раза, но описана она будет в одном месте, что имхо лучше.
> Такой же синтаксис в Rust.
Они все единого формата, т.е. на них у клиентов универсальный обработчик, соответственно и в документации такое не описываем.
А если все же на основе какой-то ошибки нужно построить логику – то этот момент пойдет уже в другой тип документации, в которой текстом описано как работать с методами и решать задачи.
Все верно, реквест модели выглядят примерно вот так:
Ошибок есть всего грубо говоря 3 вида:
1) Ошибки валидации/маппинга реквест модели – это бандл обработает сам и вернет клиенту ошибку, т.е. внутри action доступна уже чистая модель
2) Уникальные ошибки – это ошибки с каким-то своим поведением, например 404, 403 и тд, они отлавливаются и отдается json response вместо них + статус
3) Ошибки бизнес логики – это ошибки которые нужно показать пользователю, они тоже делаются через эксепшены, одна ошибка – один класс. Внутри каждого эксепшена можно указать константу для перевода, либо покажется дефолтный текст.
Сейчас разрабатываю rest-api-bundle для Symfony и тоже хочу реализовать там автогенерацию документации swagger. Но я пошёл другим путем, запросы и ответы в бандле описываются в виде классов, а уже по этим классам будет генерироваться json схема.
Сейчас, грубо говоря, мы подгоняем хранение данных под то, как они будут использоваться. Т.е. данные в базах могут быть специально нормализованы под какой-то высоконагруженный endpoint и от этого будет профит. Но ведь получается сам подход GraphQL этому противоречит? А как с таким подходом борются с нагрузками?
Думал увидеть какую-то общую статью, где бы говорили про версионность, обратную совместимость и прочие проблемы и тд. А по факту получил рассказал про то, как плохо подошли к этому в вашей компании