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

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

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

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

/books.php?category=ruby (возвращает XML-коллекцию книг о рубине)
/books.php?id=23 (возвращает XML для конкретной книги)
/books.php?action=add&title=AdvancedRuby&description =.... & securityId = 923847203487
/books.php?action=delete&id=342&securityId=923847203487

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

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

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

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

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

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

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

Ответ 1

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

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

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

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

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

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

Ответ 2

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

Выделение:

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

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

Ответ 3

Из RestWiki:

GET для идентификатора означает "Дайте мне копию вашей информации в определенном формате документа".
PUT к этому идентификатору означает "Заменить свою информацию на мой".
POST добавляет информацию и
DELETE удаляет информацию.

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

Ответ 4

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

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

Ответ 5

Я возьму удар, чтобы он выглядел как RESTful.

/books.php?category=ruby

GET /search?type=books&category=ruby

/books.php?id=23

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

/books.php?action=add&title=AdvancedRuby&description =.... & securityId = 923847203487

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

/books.php?action=delete&id=342&securityId=923847203487

DELETE /books/342

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

POST /books/342
status=Deleted

Ответ 6

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

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

Ответ 7

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

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

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