Подтвердить что ты не робот

Получение реальности с помощью REST

Я просматриваю браузер для достойного примера простого, полностью REST API, безрезультатно. Проверено также на stackoverflow. Лучшее, что я видел, это этот пост. Несмотря на это, я все еще не понимаю. Давайте рассмотрим пример приложения, которое все мы знаем: wikipedia.

Предположим, мы хотим создать REST API для википедии. Мы ожидаем следующие глаголы:

GET /wiki/Article_name: obtains a specified page
DELETE /wiki/Article_name: deletes the page
POST /wiki/Article_name: creates a new page
PUT /wiki/Article_name: updates a page.

Факт: когда вы используете википедию в своем браузере, вы не используете интерфейс REST для навигации по ней. Я уверен, что когда вы обновляете страницу, вы никогда не используете PUT (хотя вы технически создаете новую версию страницы, поэтому POST имеет смысл). Аналогично, при удалении страницы браузер не отправляет DELETE.

Мои вопросы:

  • - это REST также интерфейс "для браузера" или только для скриптов?
  • Мы должны видеть мир HTTP исключительно глазами представительства REST? такие вещи, как GET/foo/? page = bar & action = удалить еще действительную точку зрения, или ужасные ошибки прошлого никогда не будут выполнены снова.
  • должен ли перемещаться веб-доступ и интерфейс REST или разделяться? Например, предположим, что у вас есть приложение AddressBook. Вы можете просматривать адресную книгу с помощью GET/people/, а с GET/people/1523 вы получаете эту информацию одного человека в браузере, возможно, в хорошем для печати HTML. Если вы хотите изменить свою карточку, вы бы сделали (RESTfully) PUT/people/1523, или вместо этого имели бы PUT/api/v1.0/people/1523?
  • кто-нибудь может убедить Роя Филдинга в том, чтобы получить человека и представить пример "5-летнего ребенка" для достойного (по его мнению) API REST, вместо жалуясь на то, что не является RESTful (по его мнению), чтобы весь мир мог пройти через?
4b9b3361

ОТВЕТЫ

Ответ 1

EDIT1: Как я вижу мир, для большинства программистов REST в качестве концепции будет рассматриваться при создании API.. Таким образом, REST работает на вашем рабочем столе. когда вы создаете API для потребления машинами; НЕ, когда вы говорите о веб-страницах, с которыми люди будут взаимодействовать через браузер. EDIT2: И это не означает, что браузер не RESTful (он есть). Я просто имею в виду, что, когда текущее действие происходит, когда большинство программистов-миров (тех, кто не работает для браузера) может извлечь выгоду из REST в основном в веб-сервисах.

Пусть возьмем пример приложение, которое все мы знаем: википедия.

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

GET/wiki/Article_name: получает указанную страницу

DELETE/wiki/Article_name: удаляет страницу

POST/wiki/Article_name: создает новую страницу

PUT/wiki/Article_name: обновляет страницу.

Ваша структура данных основана на модели использования человеком для Википедии, поэтому путаница.

Я предоставляю быстрый пример API для Википедии ниже, надеюсь, это поможет проиллюстрировать мою точку зрения. Это произошло очень быстро; и я не утверждаю, что это хороший дизайн API.: -)

Примечание 1: В приведенном ниже примере API я использую JSON. Что касается "RESTfulness", то это не должен быть JSON, любой формат данных, который может быть эффективно обменяться через HTTP, прекрасен. Таким образом, другими примерами могут быть XML, TXT, JPEG, AVI. Вообще говоря, "RESTfulness" применяется к заголовкам URL и HTTP, а не к телу страницы - тело остается свободным для конкретных потребностей в реализации.

Примечание 2: Я притворяюсь, что в Википедии есть внутренний, структурированный формат данных, который преобразуется в HTML-страницы - просто для того, чтобы проиллюстрировать мое мнение, поскольку Wikipedia на самом деле не является лучший пример для работы с...

Первый снимок API RESTful для Wikipedia может быть примерно таким:

api.wikipedia.com/search/keywords

Получает GET с поисковыми словами в URL-адресе, возвращает набор данных JSON идентификаторы страниц, названия страниц, URL-адреса и оценки релевантности.

api.wikipedia.com/article/id/

Принимает GET, DELETE, POST, PUT и будет работать с статьей с внутренним идентификатором, равным "id" в URL-адресе. В зависимости от метода HTTP запроса он будет:

  • GET; (в Википедии предопределенный формат данных на основе JSON.)
  • DELETE; удалить статью
  • POST; создайте новую статью (статья должна находиться в теле запроса в предопределенном формате JSON)
  • PUT; обновить статью (и целая страница должна быть отправлена ​​заново в теле)

api.wikipedia.com/media/id/

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

Быстрый взгляд на воображаемый API выше показывает ряд проблем.. и что красота REST; это просто и не мешает визуализации изменений данных.

является REST также интерфейсом "для браузера" или только для скриптов?

EDIT3 Исходный текст: Он не предназначен для браузера, он предназначен только для API, предназначенных для потребления другими клиентами или службами, которые являются "машинами".

Я хотел бы изменить это на: Браузер RESTful. Это также заданный, т.е. С установленной базой, и крайнее время, необходимое для замены IE6, ясно, что браузеры, которые мы имеем сегодня, будут с нами в течение длительного времени. И текущие браузеры ничего не делают со специальными микроформатами или сайтами с XHTML для разметки страницы и XHTML для передачи данных, они оставляют все, что вам нужно сделать с помощью Javascript.

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

Относительно других технологий веб-сервисов, REST имеет значительное преимущество в простоте отладки. Вы можете просто запустить клиент на свой компьютер, отправить URL-адрес и сразу увидеть ответ. (ОК, то же самое относится и ко многим веб-сервисам на основе XML, но машинный XML для меня нецелесообразно "читать".)

должен ли мы видеть мир HTTP исключительно глазами представления REST?

Ehh, no. Браузер обрабатывает, что, 97% сегодняшнего трафика сайта в среднем?

если веб-доступ и интерфейс REST будут перемешаны или разделены?

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

Ответ 2

является REST также интерфейсом "для браузера" или просто для скриптов

И. На самом деле браузер - отличный пример клиента REST. Тот факт, что он использует только подмножество интерфейса HTTP, не нарушает равномерного ограничения интерфейса. В любом случае, POST в значительной степени является подстановочным глаголом. Сценарии определяются в описании REST как "загрузка кода" и играют неотъемлемую часть интерфейса REST.

Обновление: Равномерное ограничение интерфейса REST не говорит "вы должны использовать все доступные глаголы" как RESTful. Он говорит, что если вы используете глагол, используйте его для выполнения действия, которое согласуется с ожидаемым поведением.

должен ли мы видеть мир HTTP исключительно глазами REST представление?

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

Запрос GET /foo/?page=bar&action=delete нарушает правила HTTP и, следовательно, нарушает ограничение REST для однородного интерфейса. Но он сначала разбивает HTTP-код!

Update: В разделе 9.1.1 спецификации спецификаций HTTP RFC 2616 говорится: "В частности, было установлено, что методы GET и HEAD НЕ ДОЛЖНЫ иметь значение принятия каких-либо действий, кроме поиска". Выполнение действия удаления с помощью GET, безусловно, нарушает правила HTTP.

если веб-доступ и REST интерфейс должен быть смешанным или отдельным?

По-моему, они должны быть одинаковыми. На самом деле XHTML на самом деле является отличным форматом для предоставления результатов как интерфейса, так и API. Он стандартизирован, он легко анализируется, он доступен для просмотра в браузере для целей отладки, он может поддерживать гипермедиа, микроформаты могут использоваться для создания семантической разметки, атрибуты класса могут использоваться для определения того, что микроформаты не покрывают. Что еще вам нужно?

Если вы планируете использовать HTML-интерфейс, зачем делать то же самое в два раза?

Может ли Рой дать нам простой пример?

Прочтите Как получить чашку кофе, чтобы получить представление о том, как должен работать REST API.

При чтении статьи помните этот важный факт, что все, кажется, забыли:

Интерфейсы REST должны быть ЛЕГКО ИСПОЛЬЗОВАТЬ, они НЕ ЛЕГКО ПРОИЗВОДИТЬ.

Ответ 3

Частичный ответ:

- такие вещи, как GET/foo/? page = bar & action = удалить еще действительную точку зрения, или ужасные ошибки прошлого никогда не будут делаться снова?

Определенно последнее. Насколько мне известно, на этот счет нет даже дебатов. Запросы GET должны быть idempotent. Использование GET для удаления - ужасное злоупотребление веб-сайтом, и я буду безжалостно смеяться над тем, кто это делает, когда googlebot приходит и стирает свою базу данных.

Сохранение поисковых систем от прикручивания - это НЕ единственная причина, по которой это не делается, поэтому не получайте сумасшедших идей об этом, потому что вы делаете это под аутентификацией.

Если вы хотите иметь кнопку удаления, нажмите кнопку удаления. Если вы действительно хотите, чтобы кнопка выглядела как ссылка, используйте javascript, чтобы щелкнуть по ссылке, выполнить сообщение (или сделать ссылку GET страницу подтверждения, что вполне приемлемо).

Ответ 4

Ты впитываешься в него.

Да, GET, PUT, POST и DELETE - все звонки RESTful. В большинстве случаев вы используете GET или POST. Когда вы переходите к URL-адресу, на веб-сервер отправляется запрос GET. Когда вы отправляете форму, это может быть GET или POST, в зависимости от элемента. Однако DELETE и PUT являются вполне допустимыми вызовами при правильных обстоятельствах, например WebDAV. Страница HTTP может удалить некоторые из них.

REST для 5-летнего ребенка просто означает "Клиент отправляет запрос на сервер для изменения состояния (добавление/замена/удаление/получение некоторого содержимого в случае HTTP), и сервер отвечает (возможно, доставляя контент и статус, возможно, только статус), и разговор заканчивается. Нет повторного разговора. Таким образом, почти ЛЮБОЙ обычный вызов веб-сервера - это RESTful, будь то из браузера, от JavaScript или от telnetting до порт 80 из терминальной программы.

REST обычно используется в отличие от SOAP, где веб-служба имеет возможность описать себя и свой API для клиента, а веб-службы могут быть обнаружены из каталогов. Это намного сложнее. Так что по большей части, если вы не делаете SOAP (и мыло настолько сложно, что вы не можете это сделать, не зная об этом), вы делаете REST.

Пока я обращаюсь к контрастам, некоторые buzzwordaholics будут контрастировать REST с AJAX. Они полностью ортогональны, и вполне возможно использовать методы AJAX для выполнения запросов REST или запросов SOAP. AJAX для 5-летнего ребенка просто означает, что в браузере есть какое-то программное обеспечение (это может быть JavaScript, но он также может быть Java или Flash) делает HTTP-запрос на сервер и обрабатывает ответ, а не сам браузер, поэтому дисплей не изменяется до тех пор, пока эта клиентская программа, работающая в браузере, не решит изменить DOM текущей отображаемой страницы.

Что касается ваших вопросов о том, является ли GET хорошей идеей или нет, "это зависит". GET помещает весь запрос в строку запроса. Это означает, что если этот запрос пользователь хочет сделать снова некоторое время (скажем, это страница поиска или ссылка на конкретный пост в блоге), он может быть отмечен закладкой. Недостатком является то, что строка запроса может быть только длинной, и это может привести к тому, что пользователи закроют части URL-адреса, которые им не нужны. POST, с другой стороны, может отправлять практически неограниченный контент, но вы не можете пометить его или отправить URL-адрес другу (или врагу, в зависимости от ссылки). Вы должны использовать правильный вариант для ситуации. Иногда вам нужен Philips, иногда вам нужна плоская голова.

Ваш пример GET/people/1523 и PUT/people/1523 совершенно правдоподобен, хотя это сложно сделать с обычным веб-сервером, который не будет понимать, что вы хотите использовать PUT. "люди" должны быть программой на каком-либо серверном языке, который может обрабатывать запрос. Если вы используете Java Servlets, он может быть сопоставлен сервлету любого имени. Было бы намного проще отделить ваш HTTP-запрос от глагола управления данными, например GET/people/1523/get и POST/people/1523/update (или GET/people/get/1523 и POST/people/update/1523).

Ответ 5

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

является REST также интерфейсом "для браузера" или просто для скриптов?

Когда вы просматриваете Википедию с помощью Firefox, вы управляете клиентом REST. Отсутствие поддержки PUT и DELETE не умаляет RESTfullnes взаимодействия, поскольку значение HTTP-глаголов выходит за рамки REST. Более спорным моментом может быть то, как сайты и браузеры поддерживают сеансы. Когда каждый запрос должен пониматься в контексте сеанса, вы можете сказать, что ограничение безгражданства запросов нарушено.

должен ли мы видеть мир HTTP исключительно глазами представительства REST? такие вещи, как GET/foo/? page = bar & action = удалить все еще действительную точку зрения, или ужасные ошибки прошлого никогда не будут выполнены снова?

AFAIK, это само по себе не нарушает ограничение REST, если одна и та же комбинация URI/глагола не выполняет две разные вещи. В этом случае вы нарушаете равномерное ограничение интерфейса. Я бы сказал, что этот подход плох с точки зрения отклонения от намерения протокола HTTP, но не с точки зрения REST.

должен ли интерфейс доступа и интерфейс REST перемещаться или разделяться? Например, предположим, что у вас есть приложение AddressBook. Вы можете просматривать адресную книгу с помощью GET/people/, а с GET/people/1523 вы получаете эту информацию одного человека в браузере, возможно, в хорошем для печати HTML. Если вы хотите изменить свою карточку, вы бы сделали (RESTfully) PUT/people/1523 или вместо этого имели бы PUT/api/v1.0/people/1523?

Я не вижу проблемы с API RESTful, работающим по-разному для браузеров и для других клиентов REST. Самое главное - обеспечить последовательное поведение в классе клиентов. Управление версиями API выходит за рамки REST.

кто-нибудь может убедить Роя Филдинга получить человека и представить пример "5-летнего ребенка" для достойного (по его мнению) API REST, вместо того, чтобы жаловаться на то, что не является RESTful (по его мнению), чтобы все мир может пройти через?

Это было именно то, что я почувствовал после прочтения этой публикации и приблизился к почти полному отсутствию реальных примеров.

Предложение Даррела Миллера для чашки кофе-статьи является хорошим. Если вы хотите получить еще проще, просто вернитесь к своему первоначальному примеру - браузеру. Каждый ребенок, которого я видел с помощью веб-браузера, быстро понимает, как он работает. Вы начинаете с некоторой страницы. Вы находите то, что вам нравится. Вы переходите по ссылке. Вы попадаете на другую страницу. Вы найдете там что-то, что вам нравится. Вы следуете этой ссылке и переходите на другую страницу. И так далее.

Забавно, насколько сложно доказать эту простую идею практиковать для не-браузерных клиентов. Для вдохновения вы можете проверить Sun Cloud API.

Ответ 6

Несколько современных браузеров по-прежнему не могут отправлять HTTP-запросы, кроме GET и POST. Он блокирует более широкое принятие REST. Хотя некоторые возможности для браузеров доступны (см. эту презентацию Дэвида Хайннемайера Хансона).

По словам Тима Бернерса-Ли, URL-адреса должны быть непрозрачными (хотя есть некоторые обсуждения здесь), поэтому такие вещи, как GET /foo/?bar=baz HTTP/1.1, отлично, пока GET остается идемпотентным и безопасным.

Повторное использование URL-адресов путем обращения к ним с различными типами носителей считается хорошей практикой.

Я думаю, что можно использовать RFC 5023 Протокол публикации Atom в качестве канонического примера API RESTful (по крайней мере, Рой Филдинг прокомментировал некоторые связанные с этим вопросы).

Ответ 7

<ч/" > 1. NerdDinner использует службы данных WCF, что является отличным способом правильно внедрить службы RESTful. Причина, по которой я указываю на это, а не службы данных WCF напрямую, - это публичный веб-сайт, и вы можете его использовать. 2. MediaWiki - отличный пример, поскольку они передают действия в URI, но это технически служба RESTful и показывает много интересных идей.