Рецензия на книгу: REST API Design Rulebook (Марк Масс)
Архитектура стиля RESTful становится все более и более вездесущей. Есть много причин для этого:
- Веб-уровни полны JavaScript, стремящегося выполнять простые простые запросы AJAX.
- Очевидные недостатки сильных контрактов в стиле SOAP
- Они являются хорошей альтернативой ESB для интеграции разнородных архитектур
Однако, как и шаблон проектирования MVC или методология Agile Software, многие проекты могут претендовать на использование архитектурного подхода RESTful, каждый делает это по-
своему .
В 2010 году Мартин Фаулер — в своем отличном
блоге — обсудил
модель зрелости Ричардсона . Эта модель предоставила очень хороший метод категоризации для оценки степени
RESTfullness на основе того, сколько основных принципов REST использовалось. Несмотря на то, что эта же модель упоминается в Руководстве по разработке REST API Марка Массе
, в книге Массе гораздо более подробно рассматриваются различные передовые практики REST.
Например:
- Отрицательное кэширование : добавление заголовков кэша не только для положительных ответов, но и для ответов 3xx и 4xx. Это может быть неочевидно, но может привести к хорошему повышению производительности / масштабируемости в зависимости от характера вашего приложения, моделей использования пользователей и т. Д.
- Как создать версию ваших URI, ваших представительных форм и объектов ресурсов
- Использование последовательных форм для представления связей
Кроме того, существует множество других идей и рекомендаций, некоторые из которых довольно простые, но тем не менее важные:
- Не заканчивайте URI косой чертой
- Не используйте подчеркивания в путях URI
- Поместите «api» в доменную часть пути вашего ресурса отдыха, например
https://api.dropbox.com/1/oauth/request_token
Основная причина, почему я думаю, что хорошо иметь такую книгу, заключается в том, что когда команда разработчиков пытается использовать архитектуру стиля REST, неизбежно возникают разногласия, недоразумения. Например, пословица: «
Должен ли URI оканчиваться на множественное или единственное существительное?»
Всегда полезно иметь возможность ссылаться на авторитетный отраслевой ресурс, чтобы предотвратить появление и потребление кроличьей норы в ваше драгоценное время проекта.
Кроме того, есть несколько очень быстрых и простых вещей, которые вы можете сделать, чтобы сделать REST API намного лучше, которые обсуждаются в книге. Например:
- Добавление HTTP-заголовка ETag к этому ресурсу корзины покупок при входе и выходе из него.
- Использование полей запроса для генерации частичных ответов и использование! для исключающего варианта.
Теперь о конструктивной критике. Во-первых, я не уверен, что когда-нибудь будут подходы REST. Некоторые из так называемых лучших практик можно назвать просто субъективными или
приятными . Они не имеют большого значения для функциональных или нефункциональных аспектов вашей архитектуры. Некоторые из лидеров отрасли не только используют разные подходы в своих REST API, но и иногда делают то, что предлагает Массэ. Например, Massé предлагает не включать тип расширения файла в URL-адреса REST (
см. Главу 2 ), но (на момент написания) Twitter делает именно
это (
URI:
https://api.twitter.com/1.1 /statuses/mentions_timeline.json
)
Кроме того, во многих проектах вы будете писать REST API исключительно для обслуживания JSON для веб-клиента. Это сильно отличается от общедоступного API в масштабах Twitter, Amazon и т. Д. Поэтому вам нужно спросить себя, действительно ли вам нужно вкладывать время, чтобы придерживаться каждой лучшей практики REST вместо того, чтобы просто делать то, что нужно. имеет смысл для вашего проекта. Некоторые, очевидно, имеют смысл, некоторые можно считать излишними. Например, убедитесь, что вы отправляете верный HTTP-код, когда знаете, что клиент даже не проверяет, является ли он 403 или 405.
Я думаю, что эта книга написана больше, как если бы вы разрабатывали публичный API. Если вы окажетесь в такой ситуации, вам определенно следует определенно рассмотреть все, что Массэ говорит в книге. Но обратите внимание, акцент делается на
рассмотрении, которое не всегда означает
придерживаться или принимать .
Книга очень хорошо справляется с рекомендациями, о которых многие разработчики даже не подумают (
настройка заголовков ответов, таких как длина содержимого, установка заголовка местоположения в ответах для вновь созданных ресурсов, как поддерживать HTTP 1.0, когда вы пытаются препятствовать кешированию) и, безусловно, стоит прочитать, но вы действительно должны подумать о том, что имеет смысл для вашего проекта. Как уже говорилось, некоторые из предложений быстро выигрывают, другие вы должны оценить стоимость и выгоду. Следование основным базовым принципам REST (отсутствие состояния, хорошая модель ресурсов, унифицированный интерфейс и т. Д.) — вот что действительно важно после этого, задача состоит в том, чтобы выяснить, что лучше всего подходит для каждого конкретного проекта и как максимально использовать свое время. Это будет варьироваться от проекта к проекту и будет зависеть от масштаба проекта, масштаба и т. Д. Хорошее архитектурное решение должно всегда учитывать различные варианты, но принимать соответствующее решение для соответствующего проекта.
До следующего раза, береги себя.