Веб-сайты RESTful против API RESTful. Какая разница и имеет ли это значение?

Я много читал о REST и как сделать REST "правильным способом". Большинство ресурсов используют такие термины, как веб-службы RESTful или API RESTful, однако ни одно из них не упоминает веб-сайты RESTful. Я смущен этим, учитывая, что я думаю о веб-сайте и API как о двух разных вещах. Тем не менее, когда, например, при разработке веб-сайта с использованием Rails-структуры вам постоянно напоминают о том, как RESTful все (или должно быть).

Я получаю тот факт, что REST предоставляет множество преимуществ (его архитектурные свойства) для API (например, JSON API), но я просто не вижу, как преимущество веб-сайта - быть RESTful. В качестве простого примера рассмотрим функцию входа в систему. В режиме REST это можно смоделировать, создав модель сеанса с протоколированием в соответствии с созданием нового сеанса, выводом из строя сеанса и т.д. URL-адреса выглядят примерно так:

Prefix Verb   URI Pattern                    Controller#Action
    new_user_session GET    /users/login(.:format)         sessions#new
        user_session POST   /users/login(.:format)         sessions#create
destroy_user_session DELETE /users/sign_out(.:format)      sessions#destroy

Однако эти URL-адреса не очень удобны для пользователя. С точки зрения пользователей, имеет смысл просто иметь/путь входа в систему, где отображается форма входа. Это также легче запомнить. Но если мы сделаем карту URL таким образом, что они больше не являются (как) RESTful;/login определяет ресурс. Если да, то какой?

Другим примером является домашняя страница/домашний или просто /. Как это вписывается в REST? На большинстве веб-сайтов домашняя страница представляет собой mashup из многих различных видов информации и не идентифицирует ни одного ресурса. Например, это может быть страница, в которой перечислены новейшие продукты в каталоге и последняя дата регистрации; две совершенно несвязанные вещи. Как этот RESTful?

Я понимаю, почему использование RESTful API отдельно от веб-сайта имеет смысл, но моя путаница заключается в том, как REST применяется к веб-сайтам - если это даже делает.

Ответ 1

Короткий ответ заключается в том, что никто не говорит о веб-сайтах RESTful, поскольку сайты по умолчанию RESTful. Вам действительно нужно попытаться создать веб-сайт без RESTful (хотя это было сделано - см. Ниже).

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

Позвольте мне немного подружиться. Здесь, какие веб-сайты и веб-API имеют общий характер: они оба раскрывают функциональность через ресурсы. Каждый ресурс идентифицируется URL-адресом, и каждый из них отвечает на соответствующее подмножество стандартных HTTP-методов. (Это может показаться очевидным, но посмотрите на XML-RPC или SOAP, где есть только один URL-адрес для всей системы.) Ресурс может отправлять документы клиенту (в ответ на запрос GET) и/или он может принимать документы из клиент (вместе с запросом POST или PUT).

Теперь, различия. Веб-API часто отображают четыре наиболее распространенных метода HTTP (POST, GET, PUT, DELETE) на четыре операции CRUD (создание, чтение, обновление, удаление). Веб-сайты не могут этого сделать, потому что веб-сайты работают на HTML, а HTML-формы поддерживают только два метода: GET и POST. И все же веб-сайт может легко описать все виды действий - "поиск", "следующая страница", "покупка", "недружество" - которые нетривиальны для отображения на CRUD.

Это потому, что HTML поддерживает ссылки и формы. Это то, что отсутствует в ветке "Веб-API" генеалогического древа. Не ресурсы, а машиночитаемые соединения между ресурсами. (Чтобы удалить некоторый жаргон REST, это "ограничение гипермедиа" или "гипермедиа как двигатель состояния приложения".)

"Веб-API" , как правило, игнорируют ограничение гипермедиа, потому что а) это трудно понять, и б) JSON не поддерживает ссылки или формы, поэтому трудно подчиниться гипермедийному ограничению, даже если вы этого хотите. (Это меняется с развитием таких форматов, как JSON-LD, Hydra и HAL.)

Но ограничение гипермедиа - это буквально то, что удерживает Сеть вместе. Уберите ссылки и формы, и вы останетесь с неиспользуемым беспорядком.

Python Challenge - хороший пример веб-сайта, не принадлежащего RESTful. Вы получаете стартовый URL, а затем вам нужно решить небольшую загадку, чтобы выяснить, как добраться до следующего URL-адреса в последовательности. У вас все еще есть ресурсы, и каждый ресурс имеет URL-адрес. Но связи между ресурсами скрыты. Это весело, как игра, но никто не будет запускать серьезный сайт таким образом. К сожалению, это своего рода то, что мы имеем в виду "Веб-API" .

Дальнейшее чтение

Как вы можете сказать, это сложная тема. Рискуя сделать свой собственный рог, "модель зрелости" , которую я разработал для разговора 2008 года, может помочь вам понять архитектурное различие между Всемирной паутиной (уровень 3) и большинство современных API (уровень 2). Я также рекомендовал Steve Klabnik Проектирование API Hypermedia и собственный RESTful Web API, который начинается с сравнивая веб-API с веб-сайтом, который делает то же самое.

Моя предыдущая книга RESTful Web Services также охватывает эту тему, и она бесплатна для чтения в Интернете. Однако он несколько устарел (он был опубликован в 2007 году), и в ретроспективе я не думаю, что он достаточно сильно подталкивает угол гипермедиа.

Разное

Чтобы кратко ответить на несколько второстепенных вопросов из вашего первоначального вопроса:

Существует нет технической разницы между веб-API и веб-сайтом. Веб-сайт - это веб-API, который служит для работы с документами HTML.
Один URL-адрес не более "RESTful", чем другой. Это исключительно вопрос удобства использования. На техническом уровне совсем не имеет значения, как выглядят ваши URL-адреса. /users/login.json и /login и /the-first-100-prime-numbers.gif - все равно RESTful способы ссылаться на форму входа.
Домашняя страница - это ресурс: это ресурс "домашней страницы". Его задача состоит в том, чтобы содержать самые важные биты информации и направлять клиента на другие страницы - либо напрямую через ссылки, либо косвенно через форму поиска. Ресурс не обязательно соответствует строке в базе данных или объекту в объектной модели. Ресурс может быть абсолютно любым, даже реальным объектом или абстрактным понятием. Единственное ограничение заключается в том, что ресурс должен иметь URL-адрес.
/login - это URL, поэтому да, он идентифицирует ресурс. Какой ресурс? Если это типичный сценарий, в котором при отправке "GET/login" вы получаете HTML-страницу с формой входа в систему, то это ресурс "входа в систему". Если заполнение формы входа запускает запрос "POST/login", он также действует как "процессор формы входа".

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

Надеюсь, что это поможет.