Комментарии 12
$result = (false === $data) ? ['status' => 'fail', 'code' => 12345] : ['status' => 'ok'];
Похоже, должно быть так
Используем в нескольких проектах webapi2 + swashbuckle (генератор swagger-описания из XML документации C# проекта). Итого он еще и описания делает красивые из summary.
Мне кажется, мастхэв. Трудозатрат не стоит никаких, собирается и публикуется автоматически при билде, но сильно упрощает всё — работу внешних разработчиков, внутреннюю разработку и коммуникации фронта/бэка, тестирование, работу тех. писателей…
Но и заменой тестов это считать не стоит.
Tree — не более чем абстрактный формат сериализации дерева. Семантика узлов уже определяется языками. Ну то есть можно придумать какой-нибудь язык schema.tree
, для описания других tree-языков. Что-то вроде:
$string \
$number \
$time \
$user user
name $string
age $number
friends $user
$comment comment
message $string
author $user
reply-to $comment
$article article
title $string
published $time
author $user
comments $comment
Примерно такое описание у нас было для моделей, по которым генерировался как серверный (/article/@123?fetch=comments/@
), так и клиентский (domain.artcile(123).comments()
) апи, так что в этих развесистых описаниях эндпоинтов не было никакой необходимости. При реализации протокола коммуникации (рест, вебсекеты, прц) совершенно не важно какие там модели есть на сервере, а при использовании моделей (пользователи, комментарии, статьи) совершенно не важны детали протокола.
Декларативное программирование в web-е