Должен ли веб-сайт также быть веб-ресурсом?

каждое веб-приложение-каждый веб-сайт-это сервис. (...) Функции, которые делают веб-сайт легким для веб-серфера, также делают API веб-сервиса легким для программиста.

Ричардсон и Руби, "RESTFul Web Services"

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

это не относится ко многим популярным "REST APIs" в дикой природе. API Twitter, например, находится по адресуhttp://api.twitter.com/1/, " 1 " в URI является версией самого API. Socialcast также предоставляет API REST по адресуhttps://demo.socialcast.com/api/, имя третьего уровня - это имя сети, к которой он обращается.

мне это кажется неправильным. если я имейте мой блог вhttp://www.example.com/blog, мне не нужно предоставлять API в другом месте, обслуживая JSON только для роботов. Вместо того, чтобы иметь http://www.example.com/blog/posts/ и http://api.example.com/blog/posts, два разных URI, я должен иметь только первое и несколько доступных представлений, среди которых application/json для JSON API я хочу предоставить своим пользователям.

Пример 1: браузер запрашиваю посты в своем блоге;

запрос:

curl -i 
 -H "Accept: text/html" 
 -X GET 
 http://www.example.org/blog/posts/

ответ:

 200 OK
 Content-Type: text/html; charset=utf-8

 <html><body><h1>Posts</h1><ol><li><h2>My first post ...

Пример 2: тот же URI, но на этот раз робот делает запрос;

запрос:

curl -i 
 -H "Accept: application/json" 
 -X GET 
 http://www.example.org/blog/posts/

ответ:

 200 OK
 Content-Type: text/html; charset=utf-8

 {
    "posts": [
        {
            "id": 1,
            "title": "My first post" ...

номера версий для API должны быть закодированы в поле "Accept" заголовков запроса и, прежде всего, избегать строгого ввода URI, таких как Twitter делает ("статусы / шоу.в JSON?id=210462857140252672 " или " статусы / показать / 210462857140252672.формат JSON.)"

я мог бы потерять некоторую гибкость, Перейдя на единый подход (но, не должен прохладный URIs никогда не меняется?), но я думаю, что соблюдение покоя (или, по крайней мере, моя интерпретация этого) принесет больше пользы.

какой подход более правильный: разделение API и веб-сайта или их объединение?

6
http rest url-design web

4 ответов

здесь нет правильного или неправильного. Слишком близкое следование REST и RFCs может оказаться сложным, если разработка API обусловлена конкретными требованиями клиента.

в действительности, человеческие потребители имеют различные картины поведения сравненные к клиентам АПИ, и поэтому требуют различной обработки. Самое яркое различие заключается в том, что многие API очень интенсивны для данных, предназначены для пакетных операций и сброса данных, в то время как приложения для пользователей "реактивный" и часто делает вещи шаг за шагом, запрос за запросом. Как следствие, во многих проектах API URL design is оптимальный избежать расточительствовать ресурсы клиента и сервера на множественных roundtrips сети и повторении вызовов хранения.

под капотом реализации API часто имеют разный дизайн от основного приложения, оптимизированного для операций, которые предоставляют API. Например, реализация API может использовать отдельную стратегию кэширования. Теперь, если вы разделите код оттуда, вы можете создать кластер хостов, которые обрабатывают только вызовы API. Именно здесь размещение API на другом домене становится выгодным для управление нагрузкой: отдельный домен позволяет упростить балансировку нагрузки на сайтах с высокой нагрузкой. Для сравнения, когда вы используете префикс URL /api на том же доменном имени (но имеете отдельные кластеры), вам нужен интеллектуальный (L7-aware) балансировщик нагрузки, чтобы выполнить работу по разделению потока запросов между API и кластерами веб-интерфейса, но такая нагрузка балансиры дороже.

таким образом, могут быть очень хорошие технические причины, по которым подобные Twitter отделяют API, но ссылки на другие реализации могут не относиться к вашему проекту. Если вы находитесь на ранних стадиях разработки, вы можете начать с единой схемы URL в том же домене, но в конечном итоге вы можете обнаружить, что есть хорошие реальные случаи использования, которые заставляют вас изменить подход, а затем ... рефакторинг.

P. S. Есть продолжительного обсуждения по версионированию здесь -рекомендации по управлению версиями API?

P. S. S. Я нахожу строго типизированные URL-адреса полезными для быстрой отладки. Вы можете просто поместить URL-адрес в браузер .json и быстро получить результат без переключения в командную строку. Но согласитесь с вами, что заголовок "accept" является предпочтительным методом

П. С. С. С. СЕО для API? Я вижу, как хороший дизайн URL может быть полезен, но для поисковой системы это, вероятно, не имеет значения, если ваш сервис предоставляет несколько форматов вывода на одном пути / доменном имени. В конце концов, поисковые системы построены для пользователей-людей, а пользователи-люди не потребляют XML и JSON.

7

веб и RESTful API могут вести себя по-разному.

В теории, как бы запрос типа http://mysite.com/blog/1 различает, нужно ли возвращать HTML-страницу или только данные (JSON, XML...)? Я буду голосовать за использование Accept HTTP-заголовок:

Accept: text/html <-- Web browsers
Accept: application/json <-- Applications/Relying parties consuming data or performing actions

почему Twitter, Facebook или другие сайты не смешивают веб-браузеры и проверяющие стороны? Честно говоря, я бы сказал, что это произвольное решение.

возможно, я могу предоставить один из возможных причина: URL-адреса веб-браузера/поискового робота должны быть дружественные-URLs потому что они лучше работают на SEO. По этой причине, возможно, SEO-готовые URL-адреса не очень семантичны с точки зрения REST, но они для поисковой системы или даже людей!

и наконец: что лучше (это мое мнение)?

  • вам нужно SEO, тогда используйте отдельные url.
  • вам не нужно SEO, затем унифицировать URL-адреса в тот же домен и формат.
2

я не согласен с другим ответом, что это решение должно иметь какое-либо отношение к SEO или как "дружественный" URL (роботы [написаны] людьми тоже!). Но моя интуиция говорит мне, что лучшие результаты SEO будут исходить от объединяющим URIs, так как это также объединяет pagerank в (маловероятном) случае, когда ваши URI API будут связаны с world wild web.

что это решение должны остальное на ваш сервер и клиенты способен. Если они могут установить заголовки запроса Accept, и ваш сервер достаточно умен, чтобы сделать прозрачное согласование контента, то обязательно объедините URI. Это то, что я делаю (мой единственный клиент JSON, хотя я сам, выдающий AJAX-запросы, обслуживаемые из других HTML-частей моего веб-приложения, где я контролирую заголовок Accept).

если клиент не может установить заголовки запросов, такие как веб-пользователь, желающий получить ответ json, они будут иметь значение по умолчанию (предположительно text/html). По этой причине вы можете разрешить несогласованные ответы под уникальными URIs (/foo.txt, / foo.формат RTF.) Обычно это делается путем добавления формата к URI, разделенному точкой, как если бы это было расширение имени файла (но обычно это не так, mod_rewrite делает жонглирование), чтобы старые клиенты на платформах, которым нужны расширения имени файла, могли сохранить файл со значимым.

большинство страниц на моем сайте работают примерно так:

  1. определить SQL запроса из URL запроса. (например,/cars?colour=black =>SELECT * FROM cars WHERE colour='black')
  2. выдать SQL-запрос.
  3. определите допустимый тип ответа из списка, поддерживаемого этим файлом. Обычно это HTML и HAL (т. е. JSON), хотя иногда и XML. Отступаем к text/html если ничего другого не приемлемо.
  4. если (HTML) выплюнуть <HEAD> и <NAV> (учитывая параметры: <h1>Black Cars</h1>)
  5. выплюнуть результаты, используя наиболее приемлемый тип реагирования.
    Эта функция знает, как чтобы взять объект результата SQL и превратить его в HTTP Link заголовки, поток HTML <LINK> элементы, Хэла _links ключ, поток элементов XLink, HTML <TABLE> элемент (с ячейками, содержащими <A> elements) или CSV-файл. SQL-запрос может возвращать 0 строк, и в этом случае вместо HTML-таблицы записывается удобное сообщение, если этот вывод использовался.
  6. если (HTML) выплюнуть <FOOTER>

этот основной план обрабатывает около 30 различных коллекции ресурсов в моем веб-приложении, хотя каждый из них имеет различный набор параметров, которые может вызывать URI запроса, поэтому начало каждого из них отличается с точки зрения проверки параметров.

Итак, теперь я объяснил все это, вы можете увидеть, как было бы полезно иметь все особенности каждого ресурса, обрабатываемого в одном месте, и обобщения вывода в формате X или формате Y, обрабатываемые общей библиотечной функцией. Это деталь реализации, которая облегчает жизнь и помогает мне придерживаться Не повторяйся, Максим.

1

Я определенно не согласен с подходом web-site == web-service.

проще говоря, веб-сайт должен рассматриваться как клиент, просто клиент, который потребляет веб-сервис и отображает данные в соответствующей форме для веб-использования. Так же, как мобильное приложение-это клиент, просто клиент, потребляющий тот же веб-сервис и предоставляющий данные в соответствующей форме для мобильного использования.

веб-служба является поставщиком услуг. Все другие просто клиенты; веб-сайт, android app, iphone app,...так далее.

0