Что я не понимаю о REST?

Question

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

Например, если кто-то создает сайт с рецензиями на книги, авторами, цитатами, примерами кода, комментариями и т. Д., Разработчик может сделать, например, «рецензии на книги» только для чтения для других сайтов и «комментарии», читаемые другими сайтами и доступные для записи определенным сайтам / пользователям. Идея состоит в том, чтобы использовать инфраструктуру для создания приложений, которые могут быть легко связаны с другими приложениями.

Я предполагаю включить все взаимодействия с сайтом через POST и GET, которые будут выглядеть примерно так:

• / books.php? Category = ruby ​​ (возвращает коллекцию книг XML о ruby)
• / books.php? Id = 23 (возвращает XML для конкретной книги)
• / books.php? Действие = добавить & название = AdvancedRuby & описание = .... & securityId = 923847203487
• / books.php? Действие = удаление & ID = 342 & securityId = 923847203487

Другие приложения также могут «обнаруживать и потреблять» то, что может предложить определенный сайт, делая это:

• / Discover.php (возвращает XML всех открытых классов и доступных действий)

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

Что я хочу знать, прежде чем я начну реализовывать это, есть ли важные / интересные части REST, которые я еще не понимаю, которые я должен встроить в структуру , например ::101037*

• REST требует GET, POST, PUT и DELETE. Зачем мне когда-нибудь нужны "PUT" и "DELETE"? Могу ли я отказаться от использования каких-то стандартов, если я их не использую?
• Мой файл "explore.php" работает аналогично файлу WSDL в веб-службах. Я удивлен в описаниях REST, кажется, нет стандартизированного способа обнаружения услуг, которые предлагает сервис RESTful, или есть?
• Если клиентский сайт пытается, например, добавить книгу на веб-сайт сервера и не получить ответ «успех», он просто попытается снова, пока не получит ответ. Веб-сайт сервера просто не добавит одну и ту же книгу дважды. Это мое понимание целостности данных в REST, есть что-то большее, чем это?

• со временем я хочу иметь несколько сайтов с одинаковыми расширенными классами, например «BookReview», чтобы клиентский сайт мог выполнять такой код:

  $ bookReview = new BookReview ("http://www.example.com/books.php?id=23"); $ book-> informAuthor («на нашем сайте был опубликован комментарий к обзору вашей книги ...»);

и сайт сервера отправит электронное письмо автору этого обзора. Является ли этот тип взаимодействия типов компонентом философии RESTful или REST - просто обмен данными через XML, JSON?

Answer 1

Могу ли я отказаться от использования каких-либо стандартов, если я их не использую?

Вы сами блокируетесь от стандарта HTTP. Конечно, вы можете использовать параметры GET, чтобы сделать то же самое. Это просто не REST, а что-то вроде RPC.

Могу ли я предложить книгу RESTful Web Services Леонарда Ричардсона и Сэма Руби? Это довольно весело читать и показывает различия между различными подходами.

Чтобы ответить на ваши вопросы более подробно: вам решать, каким образом вы пойдете. Теоретически вы можете делать все то же самое с подходами RESTful и RPC. С RESTful вы используете нижележащий протокол HTTP, чтобы быть протоколом. С помощью RPC вы используете HTTP как средство транспортировки и скрываете рабочие задания где-то в передаваемых данных. Это приводит к (необязательным) накладным расходам.

Просто посмотрите на два ваших примера:

• / books.php? Действие = добавить & название = AdvancedRuby & описание = .... & securityId = 923847203487
• / books.php? Действие = удаление & ID = 342 & securityId = 923847203487
  • Есть POST и PUT или DELETE, почему action = add и action = delete?
  • Есть HTTP-аутентификация. Зачем изобретать - возможно, менее безопасный - securityId?
  • Кстати: вы не должны разрешать изменения данных через GET. Это просто то, что не должно быть сделано (другая тема, хотя;))

Answer 2

Предлагаю вам прочитать этот пост Роя Филдинга.

Основной момент:

• API-интерфейс REST должен потратить почти все свои описательные усилия на определение типов носителей, используемых для представления ресурсов и управления состоянием приложения, или на определение имен расширенных отношений и / или разметки с поддержкой гипертекста для существующие стандартные типы носителей. Любое усилие, затрачиваемое на описание того, какие методы использовать с какими интересующими URI, должно быть полностью определено в рамках правил обработки для типа носителя (и, в большинстве случаев, уже определено существующими типами носителя). [Ошибка здесь подразумевает, что внешняя информация управляет взаимодействием вместо гипертекста.]

• REST API не должен определять фиксированные имена ресурсов или иерархии (очевидная связь клиента и сервера). Серверы должны иметь свободу управления своим собственным пространством имен. Вместо этого позвольте серверам инструктировать клиентов о том, как создавать соответствующие URI, например, в HTML-формах и шаблонах URI, определяя эти инструкции в типах мультимедиа и ссылочных отношениях. [Ошибка здесь подразумевает, что клиенты принимают структуру ресурса из-за внеполосной информации, такой как специфичный для области стандарт, который является ориентированным на данные эквивалентом функциональной связи RPC].

Вы, безусловно, можете добиться успеха, используя RPC-подобный подход, который вы описываете, и его легче понять, чем «правильный REST API». Наиболее неправильно понимаемый аспект REST заключается в том, что после его определения он должен автоматически работать , вы не должны определять переход к этому URI с помощью этого метода для получения этого ответа, который должен подразумеваться типами носителей, которые вы используете. доставка плюс средство, позволяющее клиентам узнать, где найти соответствующие ресурсы.

Answer 3

Из RestWiki :

• GET для идентификатора означает «Дайте мне копию вашей информации в определенном формате документа».
• PUT для этого идентификатора означает «Заменить вашу информацию моей».
• POST добавляет информацию, а
• УДАЛЕНИЕ удаляет информацию.

Имея это в виду, применить его к вашему приложению должно быть довольно просто.

Answer 4

С помощью структуры Restlet мы точно попытались обеспечить этот уровень абстракции выше деталей HTTP и сделать концепции REST более конкретными (у многих есть соответствующий класс, такой как Component, Connector и Presentation): http://www.restlet.org/

Мы прагматичные программисты, и наши пользователи разрабатывают реальные приложения с нашей средой RESTful (для Java и GWT). Сторонники REST не все педантичны, но есть кривая обучения, как для каждой крупной технологии.

Answer 5

Я сделаю удар, чтобы это выглядело как RESTful.

/ books.php? Категория = рубин

GET /search?type=books&category=ruby

/ books.php? ID = 23

GET /books/23 (or /books/23.xml)

/ books.php? Действие = добавить & название = AdvancedRuby & описание = .... & securityId = 923847203487

POST /books
title=AdvancedRuby&description=A+great+book...

/ books.php? Действие = удаление & ID = 342 & securityId = 923847203487

DELETE /books/342

Многие разработчики придерживаются GET и POST, в этом случае последний может быть:

POST /books/342
status=Deleted

Answer 6

REST - интересная и потенциально полезная технология, но, к сожалению, она, похоже, привлекает самую педантичную коллекцию разработчиков.

Кажется, что они предпочли бы, чтобы реализация следовала догмату REST, даже если это означает полную потерю функциональности. Любое отклонение от чистого REST будет рассматриваться как ересь.

Answer 7

Я не нахожу ничего особенного в ОТДЫХЕ. Для меня это отличная концепция с абстрактной точки зрения для веб-гиков, которым не приходится иметь дело с более серьезными проблемами кодирования, связанными со сложной HTTP-связью.

Было бы неплохо, если бы был доступен REST API, который абстрагировал нас от всех HTTP. Но это не так. Вместо этого сторонники REST должны выполнять работу по продажам, чтобы вы написали такой API со всеми сопутствующими проблемами отладки и тестирования.

В тот день, когда я увижу заголовок REST 1.0, я еще раз посмотрю, чтобы найти преимущество, стоящее усилий.