Лучшие практики RESTful API

Сначала вы должны прочитать главу 5 Архитектурные стили и проектирование сетевых Архитектуры программного обеспечения, Рой Томас Филдинг. Вы узнаете из первых рук об архитектурных ограничениях, элементах и ​​представлениях REST.

Основная проблема для меня сейчас заключается в том, что именно должно быть метаданными ответа, например, какие другие полезные элементы я могу добавить, кроме «Кода ответа» и «Сообщения ответа».

Одним из архитектурных элементов REST являются представления. Представления позволяют клиенту интерпретировать ответ. В случае RESTful HTTP-представления реализуются MIME-типом. Для получения дополнительной информации см. [2]. Другими аспектами, которые вы должны учитывать, являются URI, поддерживаемые методы HTTP, параметры URL и тело сообщения.

Вторая проблема для меня заключается в том, должен ли запрос быть асинхронным, или запрос, или и то, и другое.

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

И последняя проблема заключается в том, какую технику я должен использовать для связи с отслеживанием состояния, такой как JWT или базовая аутентификация и т. д.

JWT и базовая аутентификация являются методами аутентификации без сохранения состояния. Термин «без сохранения состояния» означает, что клиентский запрос содержит всю информацию, необходимую серверу для обработки клиентского запроса.

1) МЕТА-данные — представления ресурсов должны управляться HATEOAS в соответствии с Филдинг сам. Таким образом, вы можете добавить ссылки на связанные ресурсы в метаданные.

2) Синхронизация/асинхронность. Это зависит от того, что пытается сделать API. Если он вызывает длительный процесс, асинхронный API является естественным выбором. В противном случае придерживайтесь Sync API.

3) Связь с сохранением состояния. Быть без гражданства является одним из ограничений REST-архитектура. Контекст клиента не должен храниться на сервере между запросами. Клиент отвечает за управление состоянием приложения.