Мабуть, REST - це лише сукупність умов щодо використання HTTP . Цікаво, яку перевагу надають ці конвенції. Хтось знає?
Відповіді:
Я не думаю , що ви отримаєте хорошу відповідь на це, почасти тому , що на самому ділі ніхто не погоджується на те , що REST є . Сторінка вікіпедії важка для мовних слів і легких для пояснень. Сторінка дискусії вартує просто неба, щоб побачити, наскільки люди не згодні з цим. Наскільки я можу сказати, але REST означає це:
Замість того , щоб випадково іменований-акцессори URL - адреса та використання GETдля всіх здобувачів і POSTдля всіх сеттерів, ми намагаємося , щоб ці URL - адреса визначити ресурси, а потім з допомогою HTTP - дій GET, POST, PUTі DELETEробити речі для них. Тож замість
GET /get_article?id=1
POST /delete_article id=1
Ви б зробили
GET /articles/1/
DELETE /articles/1/
А потім POSTі PUTвідповідати операціям "створити" та "оновити" (але ніхто не погоджується в який бік).
Я думаю, що аргументи кешування неправильні, тому що рядки запитів, як правило, кешовані, і крім того, вам не потрібно їх використовувати. Наприклад, джанго робить щось подібне дуже легко, і я б не сказав, що це REST:
GET /get_article/1/
POST /delete_article/ id=1
Або навіть просто включити дієслово в URL:
GET /read/article/1/
POST /delete/article/1/
POST /update/article/1/
POST /create/article/
У цьому випадку GETозначає щось без побічних ефектів і POSTозначає щось, що змінює дані на сервері. Я думаю, що це, можливо, трохи зрозуміліше і простіше, тим більше, що ви можете уникнути всієї речі PUT-vs- POST. Крім того, ви можете додати більше дієслів, якщо хочете, так що ви не штучно пов'язані з тим, що пропонує HTTP. Наприклад:
POST /hide/article/1/
POST /show/article/1/
(Або що завгодно, важко придумувати приклади, поки вони не трапляться!)
Отже, на закінчення я бачу лише дві переваги:
synchronize("/articles/1/")або що завгодно. Це сильно залежить від вашого коду.Однак я думаю, що є досить великі недоліки:
PUTі POSTє. Англійською вони означають подібні речі ("Я збираюся поставити / розмістити повідомлення на стіні.").Отже, на закінчення я б сказав: якщо ви дійсно не хочете докладати додаткових зусиль, або якщо ваша служба дійсно добре підходить до операцій CRUD, збережіть REST для другої версії вашого API.
Щойно я зіткнувся з ще однією проблемою з REST: Непросто в одному запиті зробити більше ніж одну річ або вказати, які частини складного об’єкта ви хочете отримати. Це особливо важливо для мобільних пристроїв, коли час подорожі може бути значним, а з'єднання ненадійними. Наприклад, припустимо, ви отримуєте повідомлення на часовій шкалі у фейсбуці. «Чистий» спосіб REST був би чимось подібним
GET /timeline_posts // Returns a list of post IDs.
GET /timeline_posts/1/ // Returns a list of message IDs in the post.
GET /timeline_posts/2/
GET /timeline_posts/3/
GET /message/10/
GET /message/11/
....
Що таке смішно. API в Facebook досить чудовий IMO, тож давайте подивимося, що вони роблять:
За замовчуванням більшість властивостей об’єкта повертаються, коли ви робите запит. Ви можете вибрати поля (або з'єднання), які потрібно повернути, за допомогою параметра запиту "поля". Наприклад, ця URL-адреса поверне лише ідентифікатор, ім’я та зображення Бена: https://graph.facebook.com/bgolub?fields=id,name,picture
Я поняття не маю, як ви зробили щось подібне з REST, і якщо ви зробили це, чи все одно це вважатиметься REST. Я, безумовно, ігнорую всіх, хто намагається сказати вам, що ви цього не повинні робити (особливо, якщо причина "тому, що це не REST")!
/user/{id}, то це не є спокійним". Поміркуйте: чи повинен ваш веб-переглядач попередньо запрограмований, знаючи, як отримати HTML для питання stackoverflow. сторінку?
Простіше кажучи, REST означає використовувати HTTP таким, яким він мав бути.
Погляньте на дисертацію Роя Філдінга про REST . Я думаю, що кожна людина, яка займається веб-розробкою, повинна її читати.
Як зауважимо, Рой Філдінг також є одним із ключових драйверів, що стоять за протоколом HTTP.
Щоб назвати деякі оновлення:
Простіше кажучи: НІКОЛИ .
Не соромтеся звертати увагу, але я все ще думаю, що реальної вигоди від не-REST HTTP немає. Усі поточні відповіді недійсні. Аргументи з найбільш голосованої відповіді:
З REST потрібен додатковий рівень зв'язку для сценаріїв на стороні сервера та клієнта => це насправді складніше, ніж використання HTTP, який не REST.
Кешування може управлятися заголовками HTTP, що надсилаються сервером. REST не додає жодних функцій, відсутніх у не-REST.
REST не допомагає вам організувати речі. Це змушує вас використовувати API, підтримуваний бібліотекою на стороні сервера, яку ви використовуєте. Ви можете організувати свою програму аналогічно (або краще), коли ви використовуєте не-REST підхід. Наприклад, див . Маршрутизатор Model-View або MVC .
Не зовсім правда. Все залежить від того, наскільки ви добре організуєте та документуєте свою заявку. REST не буде чарівно покращити ваш додаток.
Найбільшою перевагою IMHO, яку дозволяє REST, є скорочення зв'язку клієнт / сервер. Набагато простіше розвивати інтерфейс REST з часом, не порушуючи існуючих клієнтів.
Кожен ресурс має посилання на інші ресурси, або в ієрархії, або посиланнях, тому їх легко переглядати. Це перевага для людини, що розвиває клієнта, врятує його / вона від постійних консультацій з документами та надання пропозицій. Це також означає, що сервер може змінювати імена ресурсів в односторонньому порядку (до тих пір, поки клієнтське програмне забезпечення не жорстко кодує URL-адреси).
Ви можете КРУГАТИ свій шлях у будь-яку частину API або використовувати веб-браузер для навігації по ресурсах. Полегшує налагодження та тестування інтеграції набагато простіше.
Дозволяє вказувати дії, не вимагаючи правильного формулювання. Уявіть, якби НПЗ та сетери не були стандартизовані, а хтось використовував retrieveі defineнатомість. Вам слід запам'ятати правильне дієслово для кожної окремої точки доступу. Знаючи, що існує лише декілька дієслівних лічильників, які вирішують цю проблему.
Якщо у вас немає GETресурсу, ви можете бути впевнені, що отримаєте 404помилку в RESTful API. Порівнюйте його з не-RESTful API, який може повернутись {error: "Not found"}загорнутий у Бога, знає скільки шарів. Якщо вам потрібен додатковий простір, щоб написати повідомлення розробнику з іншого боку, ви завжди можете використовувати тіло відповіді.
Уявіть два API з однаковим функціоналом: один слід за REST, а інший ні. Тепер уявіть наступних клієнтів для цих API:
Відпочинок:
GET /products/1052/reviews
POST /products/1052/reviews "5 stars"
DELETE /products/1052/reviews/10
GET /products/1052/reviews/10
HTTP:
GET /reviews?product_id=1052
POST /post_review?product_id=1052 "5 stars"
POST /remove_review?product_id=1052&review_id=10
GET /reviews?product_id=1052&review=10
Тепер подумайте про наступні питання:
Якщо перший дзвінок кожного клієнта спрацював, наскільки впевнені, що ви можете бути і іншими?
Було проведено суттєве оновлення API, яке може змінити ці точки доступу або не змінити їх. Скільки документів вам доведеться перечитати?
Чи можете ви передбачити повернення останнього запиту?
Ви повинні відредагувати опублікований огляд (перед тим, як видалити його). Чи можете ви це зробити, не перевіряючи документи?
Рекомендую поглянути на Райана Томайко, як я пояснив REST своїй дружині
Витяг із посилання waybackmaschine:
Як щодо прикладу. Ви вчитель і хочете керувати студентами:
Якщо системи веб-інтерфейсом, тобто, ймовірно, URL для кожного з імен , які беруть участь тут: student, teacher, class, book, room, etc. ... Якби для кожної URL-адреси було машиночитане представлення, то було б тривіально закріплювати нові інструменти на системі, оскільки вся ця інформація була б споживаною стандартним чином. ... Ви можете створити загальнодержавну систему, яка змогла б поговорити з кожною з окремих шкільних систем, щоб зібрати результати тестування.
Кожна з систем отримувала б інформацію один від одного за допомогою простого HTTP GET. Якщо одній системі потрібно щось додати до іншої системи, вона використовуватиме HTTP POST. Якщо система хоче щось оновити в іншій системі, вона використовує HTTP PUT. Єдине, що залишається розібратися - це як мають виглядати дані.
Я б запропонував усім, хто шукає відповідь на це питання, пройти цей «слайд-шоу» .
Я не міг зрозуміти, що таке REST і чому він такий крутий, його плюси і мінуси, відмінності від SOAP - але це слайд-шоу було настільки геніальним і легким для розуміння, тому мені зараз набагато зрозуміліше, ніж раніше.
Кешування.
Є й інші більш глибокі переваги REST, які обертаються навколо еволюціоністської здатності через вільне з'єднання та гіпертекст, але механізми кешування є основною причиною, коли вам слід піклуватися про RESTful HTTP.
GET /get_article/19/і POST /update_articleякщо кешування - це ваша турбота. Ви все ще можете зробити все , що тільки з GETі POSTі я вважаю , RESTозначає «використання GET, POST, PUTі DELETEтільки.» а не лише "Не використовуйте рядки запитів". тож, що я запропонував, не було б REST. Потім знову ніхто не може погодитись, що REST це таке, тому я кладу це у відро з "Веб 2.0".
Це записано в дисертації Філдінга . Але якщо ви не хочете багато читати:
Можна все робити тільки з POST та GET? Так, це найкращий підхід? Ні, чому? тому що у нас є стандартні методи. Якщо ви ще раз задумаєтесь, можна було б зробити все, використовуючи лише GET .. так чому б нам взагалі не турбуватися використовувати POST? Через стандарти!
Наприклад, сьогодні, думаючи про модель MVC, ви можете обмежити свою програму реагувати лише на конкретні типи дієслів, як POST, GET, PUT та DELETE. Навіть якщо під кришкою все імітується на POST та GET, не має сенсу мати різні дієслова для різних дій?
Відкриття набагато простіше в REST. У нас є документи WADL (схожі на WSDL у традиційних веб-сервісах), які допоможуть вам рекламувати свою послугу у світі. Ви також можете використовувати UDDI відкриття. З традиційними HTTP POST та GET люди можуть не знати вашого запиту на повідомлення та схеми відповідей, щоб зателефонувати вам.
Однією з переваг є те, що ми можемо не послідовно обробляти XML-документи та знемалювати дані XML з різних джерел, таких як об’єкт InputStream, URL-адреса, вузол DOM ...
@Timmmm, про вашу редакцію:
GET /timeline_posts // could return the N first posts, with links to fetch the next/previous N posts
Це значно зменшить кількість дзвінків
І ніщо не заважає вам створити сервер, який приймає параметри HTTP для позначення значень поля, які можуть захотіти ваші клієнти ...
Але це деталь.
Набагато важливішим є той факт, що ви не згадали про величезні переваги архітектурного стилю REST (набагато краща масштабованість, через безгромадяність сервера; набагато краща доступність, через безгромадяність сервера; набагато краще використання стандартних сервісів, таких як кешування для наприклад, при використанні архітектурного стилю REST; значно менша зв'язок між клієнтом і сервером через використання рівномірного інтерфейсу; тощо. тощо)
Щодо вашого зауваження
"Не всі дії легко відображаються в CRUD (створювати, читати / отримувати, оновлювати, видаляти)."
: RDBMS також використовує підхід CRUD (SELECT / INSERT / DELETE / UPDATE), і завжди є спосіб представити та діяти на моделі даних.
Щодо вашого вироку
"Ви навіть не можете мати справу з ресурсами типу об'єкта"
: RESTful дизайн, по суті, є простим дизайном - але це НЕ означає, що проектувати його просто. Ви бачите різницю? Вам доведеться багато подумати над концепціями, які ваша програма буде представляти і обробляти, що потрібно робити, якщо ви хочете, щоб представити це за допомогою ресурсів. Але якщо ви зробите це, ви закінчите більш простий та ефективний дизайн.
Пошукові системи можуть ігнорувати рядки запитів.