Лучшие практики API RESTful
Я являюсь разработчиком Android, а также немного знаком с разработкой RESTful API. В настоящее время я создаю API, используя Dot Net Web API. Все работает нормально, но я все еще занимаюсь дизайном.
Основная проблема для меня сейчас заключается в том, какими именно должны быть метаданные ответа, например, какие другие полезные элементы я могу добавить, кроме "кода ответа" и "сообщения ответа".
Второе беспокойство для меня заключается в том, что запрос должен быть асинхронным, или запрос, или оба.
И последнее, что меня беспокоит, - это метод, который я должен использовать для связи с состоянием, такой как JWT, обычная аутентификация и т. Д. Без сохранения состояния.
2 ответа
Сначала вы должны прочитать главу 5 " Архитектурные стили и проектирование сетевых программных архитектур " Роя Томаса Филдинга. Вы узнаете из первых рук об архитектурных ограничениях, элементах и представлениях REST.
Основная проблема для меня сейчас заключается в том, какими именно должны быть метаданные ответа, например, какие другие полезные элементы я могу добавить, кроме "кода ответа" и "сообщения ответа".
Одним из архитектурных элементов REST являются представительства. Представления позволяют клиенту интерпретировать ответ. В случае RESTful HTTP-представления реализуются MIME-типом. Для получения дополнительной информации см. [ 2]. Другими аспектами, которые вы должны рассмотреть, являются URI, поддерживаемые методы HTTP, параметры URL и тело сообщения.
Второе беспокойство для меня заключается в том, что запрос должен быть асинхронным, или запрос, или оба.
Одним из архитектурных ограничений REST является архитектурный стиль клиент-сервер. Поэтому ваш сервер должен обрабатывать одновременные запросы для обработки более одного клиентского запроса одновременно. Если запрос, метод или функция обрабатываются асинхронно, значение RESTful не имеет значения.
И последнее, что меня беспокоит, это метод, который я должен использовать, чтобы установить связь с состоянием, такую как JWT, обычная аутентификация и т. Д.
JWT и базовая аутентификация являются методами аутентификации без сохранения состояния. Термин "состояние без состояния" означает, что клиентский запрос содержит всю информацию, необходимую серверу для обработки клиентского запроса.
1) Данные META - Представления ресурсов должны управляться HATEOAS согласно самому Филдингу. Поэтому вы можете добавить ссылки на связанные ресурсы в метаданные.
2) Sync / Async - это зависит от того, что пытается сделать API. Если он вызывает длительный процесс, Async API является естественным выбором. В противном случае придерживайтесь Sync API.
3) Связь с сохранением состояния. Отсутствие состояния является одним из ограничений архитектуры REST. Клиентский контекст не должен храниться на сервере между запросами. Клиент несет ответственность за управление состоянием приложения.