Отже, служба RESTful має в своєму словнику фіксований набір дієслів. Веб-сервіс RESTful бере це з методів HTTP. Існують деякі передбачувані переваги щодо визначення фіксованої лексики, але я не розумію цього. Можливо, хтось може це пояснити.

Чому фіксований словниковий запас, визначений REST, краще, ніж динамічно визначати словник для кожної держави? Наприклад, об'єктно-орієнтоване програмування - популярна парадигма. RPC описаний для визначення фіксованих інтерфейсів, але я не знаю, чому люди припускають, що RPC обмежений цими протипоказаннями. Ми могли динамічно вказати інтерфейс так само, як служба RESTful динамічно описує його структуру вмісту.

REST повинен бути вигідним тим, що може рости без розширення словникового запасу. Послуги RESTful динамічно зростають, додаючи більше ресурсів. Що не так у розширенні служби, динамічно вказуючи словник для кожного об'єкта? Чому ми просто не використовуємо методи, визначені на наших об'єктах як словниковий запас, і наші служби описують клієнту, що це за методи, і чи мають вони чи ні побічні ефекти?

По суті, я відчуваю, що опис структури ресурсів на стороні сервера еквівалентно визначенню словникового запасу, але ми змушені використовувати обмежений словниковий запас, в якому взаємодіють з цими ресурсами.

Чи дійсно фіксований словник відв'язує проблеми клієнта від турбот сервера? Я, безумовно, повинен бути пов'язаний з деякою конфігурацією сервера, це зазвичай розташування ресурсів у службах RESTful. Поскаржитися на використання динамічного словника видається несправедливим, оскільки нам доводиться динамічно міркувати, як так чи інакше зрозуміти цю конфігурацію. Служба RESTful описує переходи, які ви можете здійснити, ідентифікуючи структуру об'єкта за допомогою гіпермедіа.

Я просто не розумію, що робить фіксований словник кращим, ніж будь-який самоописуючий динамічний словник, який легко може дуже добре працювати в службі, подібній RPC. Це лише неправильне обґрунтування обмежувальної лексики протоколу HTTP?

Рефлексія

Просто, щоб прояснити свої думки трохи краще, ніж я зробив. Припустимо, ви розробляєте будь-який інтерфейс API загального призначення, можливо, навіть не для веб-сторінок. Були б ви щасливі, якби хтось сказав, що ви можете використовувати лише ці назви методів на своїх об'єктах? REST не обмежується HTTP, але врахуйте ситуацію, коли кожен API, який ви пишете, підключений до Інтернету або іншим чином просто складається з об'єктів, що містять методи GET POST PUT і DELETE. Тож той метод object.foo, який ви хотіли визначити, неможливий. Ви повинні визначити новий об'єкт, який називається foo, та назвати його метод GET. Це по суті, як працює REST, і мені це стає незручно думати про це. У вас немає кращого загального розуміння того, що робить foo, ви просто змушені були створити новий об’єкт для того, що є по суті методом на батьківському об'єкті. Крім того, ваш API не менш складний, ви просто приховали складність інтерфейсу, створивши більше об’єктів. RESTful веб-сервіси змушують нас використовувати інтерфейс, який може бути, а може бути і недостатнім у контексті API, який ми відкриваємо. Можливо, є вагома причина для цього з API-інтерфейсами, однак веб-сторінками, але це вагома причина не приймати стандартні інтерфейси для кожного об'єкта в кожному API загального призначення. Буде вдячний практичний приклад.

Термінологія «дієслово» та «іменник» тут дещо не прикро. Як ви вже згадували, ви можете легко створити об'єкт для функції. Усі об'єктно-орієнтовані мови, окрім Java, мають вбудовану трансформацію, і в Java ви все-таки робите це весь час, все-таки закінчуючи безліччю об'єктів одним методом, і часто один називається "виклик", "виконання", "застосувати" або щось подібне (тож це мови програмування, де розрізнення "дієслова" / "іменника" насправді не має сенсу).

"Дієслова" REST більше схожі на класифікацію ваших методів на гетерів, сеттерів (делетерів; можна вважати видом сеттерів) та інших. І намагаються робити все з геттерами та сетерами. Причиною цього є:

1. Простіша семантика в умовах збою зв'язку, оскільки і геттери, і сетери є безсильними. Отримати ресурс двічі не має додаткового ефекту, а також не встановлює його на вже встановлене значення.
2. Визначення деякої семантики, яку можна використовувати, можливо, кешуючи проксі, який не розуміє конкретний інтерфейс. Геттери кешуються, а сетери, як відомо, скасовують кеш.

HTTP розроблявся з самого початку з урахуванням кеш-пам'яті та відмовостійкості, тому ці два моменти призводять до використання чотирьох основних методів:

• GETє геттером. Передбачається, що він не змінює стан сервера і не повертає одне і те ж значення кожного разу з можливістю вказувати політику закінчення терміну дії та повторної перевірки.
• PUTі DELETEє сеттером і делетером (= сеттер з нулем). Вони, як правило, не використовуються в контексті звичайного Інтернету, але мають сенс для REST.
• POST є загальною кухонною мийкою «виклик», для якої схованки не можуть припускати нічого.

REST - це схема дизайну, що описує використання необмежених протоколів HTTP або подібних мережевих протоколів для реалізації інтерфейсу, який дозволяє легко керувати несправностями шляхом простого повторного повторного спроби та чудово працює з кешуванням проксі-серверів.

Це не відповідає легко звичайному об'єктно-орієнтованому API програмування. Я думаю, що це насправді гарна річ. Проблеми взаємодії через мережу, яка за своєю суттю є ненадійною та де обхідні маршрути набагато повільніші, ніж передача навіть помірного обсягу даних, що вимагає іншого дизайнерського підходу, ніж інтерфейс API, тому коли це виглядає інакше, люди не намагаються застосовувати настільки непрацездатний досвід з іншого домену (у цьому є SOAP, XML-RPC і подібне; це схоже на виклики процедур, але не працює як це, і в кінцевому підсумку виникає біль для роботи).

Основна ідея полягає в тому, що складність виражається через представлення ресурсів, і тому додаткові дієслова не потрібні. Як дехто сказав - "У REST іменники хороші, дієслова - погані".

Якщо ви подивитесь на чотири дієслова REST, вони можуть бути відображені до основних операцій CRUD, по суті дозволяючи вам робити все, що завгодно, зі своїми ресурсами. Тобто -

POST - Створення ресурсу

GET - Прочитайте ресурс

PUT - оновлення ресурсу

DELETE - Видалення ресурсу

Що ще потрібно?

Розглянемо мову, де всі конструкції (наприклад, функції) є об'єктами. Тоді дієслова RESTful просто називають конвенції та заяви про призначення. Для JavaScript ви можете визначити фіксований синтаксис дієслова, такий як INVOKE для виклику функції, DELETE (те саме, що видалити у js) для видалення об'єкта на іншому об’єкті, SET для призначення значення та RETURN для повернення значення. Ми могли б використовувати дієслова HTTP для позначення еквівалентної функції POST - викликати, PUT - призначити значення, GET - повернути значення, - DELETE - видалити об'єкт. Мене захопила думка, що методи HTTP насправді описують об'єктні методи, фактичні об'єктні інтерфейси, що я не зрозумів, що він може насправді описувати поняття на більш низькому рівні, наприклад, основні мовні конструкції, які чітко фіксовані та кінцеві у всіх здорові мови.

І звичайно, це корисно для маршрутизації / проксі, щоб мати закріплений словник, на який можна подумати.

• Тому що професійний програміст передбачає сотні, якщо не тисячі назв методів інакше. Те, що здається безглуздим на меншому малому, може бути дуже великою справою, оскільки додаток стає більше.

• Тому що немає необхідності в стандартах щодо назв методів, коли вони вже визначені.

• Тому що головна мета коду є читабельною без таких додаткових перекладів.

• Тому що це заохочує і сприяє визначенню "коли" іншого класу.

• Коли ви переймаєте код, це розумно і реально зрозуміти, що і як це робить набагато швидше.

• Він містить загальну лексику і, таким чином, рівень абстракції, щоб ви могли зосередитись на інших деталях і бачити закономірності.

• Це полегшує пошук помилок, оскільки загальний код та підходи легко перевіряти.

• Коли ви працюєте з декількома «шарами», такими як один у веб-розробці, знаючи, які URL-адреси відповідають назвам дій, дуже зручним для налагодження.

Загалом вам це не завжди потрібно, але, як і більшість стандартів, має багато сенсу намагатися використовувати його!

Альтернатива - щось жахливе: WSDL (він же мова визначення веб-служби), що є (незграбним) способом програмного опису (дещо) довільного APIS.

REST сильно обмежує дієслова, підштовхуючи майже всі варіанти застосування до корисного навантаження документа. Перевага цього полягає в тому, що багато клієнтських реалізацій можуть спілкуватися з багатьма неоднорідними службами. Клієнти та сервери можуть бути абсолютно невідомі один одному, деякі ще не написані.

Є подкаст, в якому Стефан Тілков добре пояснює REST .

Так, у api rest є фіксований набір дієслів, але це не повинно обмежуватися (або включати GET, POST, PUT, DELETE). Я б розглядав GET, POST, PUT, DELETE як реалізацію за замовчуванням REST, яка працює для 80% всіх систем там.

Інші системи, які реалізують більше, ніж грубі операції, можуть (і роблять) реалізувати власні дієслова для своїх REST API. Такі дієслова, як «Публікувати», «Споживати», «Оцінювати», «Коментувати», «Пошук», «Огляд», можна додавати та реалізовувати в системі REST. Хоча деякі можуть сказати, що більший словниковий запас може ускладнити його, моя відповідь - це залежить. Якщо ваш цільовий користувач - керівники технологій, які розуміють, що таке POST, так, це може бути складніше; однак, якщо цільовими користувачами вашого API є реальні люди (тобто люди, які не кодують і не знають, що таке POST), то справжні дієслова набагато простіше використовувати. Насправді наявність відповідного набору дієслів для вашого API допомагає тримати короткі URL-адреси (що важливо, якщо ви бажаєте, щоб користувачі вводили їх у браузері. Якщо ви використовуєте власну лексику, я хочу переконатися, що ваш API та його дієслова добре задокументовані. Використовуючи користувальницьку програму REST, ви хочете переконатися, що ваші "дії лише для читання" як HTTP GET та "запис дій" з POST.

Соціальна мережа для підлітків Piczo.com (нехай спочиває спокій) представила розширений API REST (включаючи згадані вище дієслова), який був реалізований на 7 різних мовах!

Просто - це добре.

Бувають випадки, коли вам потрібні додаткові дієслова та складність, але більшість проблем можна звести до простих дій CRUD над ресурсами, і саме це REST намагається сприяти. Коли ви думаєте про більшість веб-додатків, врешті-решт вони читають і зберігають записи в сховищі даних, в яких використовуються ті ж самі прості дії.

object.foo () - це все добре, але що він робить? Що це повертається? Це модифікація стану об'єкта чи будь-якої його залежності? Ви можете зателефонувати йому двічі і отримати однаковий результат, або це дасть вам два різних значення? Якщо у вас також є object.bar (), чи потрібно їх викликати у певному порядку?

Для використання багатого API потрібно багато знань, і вони, як правило, мають власні умови (наприклад, setFoo буде мутувати об'єкт, getBar, ймовірно, ідентичний, розпоряджається () або знищується () означає відсутність інших дзвінків по тому ж об'єкту буде можливо, тощо ...)