Ідея RE презентаційного S tate T ransfer полягає не в тому, щоб отримати доступ до даних найпростішим можливим способом.
Ви запропонували використовувати поштові запити для доступу до JSON, що є абсолютно правильним способом доступу / маніпулювання даними.
REST - це методологія змістовного доступу до даних. Коли ви побачите запит у REST, він повинен негайно визначити, що відбувається з даними.
Наприклад:
GET: /cars/make/chevrolet
швидше за все, повернуться до списку Chevy автомобілів. Хороший файл REST може навіть включати деякі параметри виводу в рядок запитів, наприклад, ?output=jsonабо ?output=htmlякий би дозволив одержувачу вирішити, в який формат інформації повинна бути закодована.
Після недовгих роздумів про те , як розумно включити типізації даних в REST API, я прийшов до висновку , що найкращий спосіб визначити тип даних , явно було б з допомогою вже існуючого розширення файлу , такі як .js, .json, .htmlабо .xml. Відсутнє розширення файлу за замовчуванням до будь-якого формату за замовчуванням (наприклад, JSON); розширення файлу, яке не підтримується, може повернути 501 Not Implementedкод статусу .
Ще один приклад:
POST: /cars/
{ make:chevrolet, model:malibu, colors:[red, green, blue, grey] }
швидше за все, буде створено нову chevy malibu в db з відповідними кольорами. Я можу сказати, що ймовірно , що apti REST не потребує прямого зв’язку зі структурою бази даних. Це просто маскуючий інтерфейс, щоб захищати справжні дані (думати про це як про аксесуари та мутатори для структури бази даних).
Тепер нам потрібно перейти до питання про самопочуття . Зазвичай REST реалізує CRUD через HTTP. HTTP використовує GET, PUT, POSTі DELETEдля запитів.
Дуже спрощена реалізація REST могла використовувати наступне картографування CRUD:
Create -> Post
Read -> Get
Update -> Put
Delete -> Delete
Існує проблема з цією реалізацією: повідомлення визначено як метод без ідентифікації. Це означає, що наступні виклики одного і того ж методу Post призводять до різних станів сервера. Отримати, поставити та видалити - є ідентичними; що означає, що виклик їх кілька разів повинен призводити до ідентичного стану сервера.
Це означає, що запит, такий як:
Delete: /cars/oldest
насправді можна реалізувати як:
Post: /cars/oldest?action=delete
Тоді як
Delete: /cars/id/123456
це призведе до того ж стану сервера, якщо ви зателефонуєте йому один раз або якщо ви зателефонуєте 1000 разів.
Кращим способом обробки вилучення oldestпредмета було б запит:
Get: /cars/oldest
і скористайтеся IDотриманими даними, щоб зробити deleteзапит:
Delete: /cars/id/[oldest id]
Проблема з цим методом /carsполягала б у тому, якщо інший елемент було додано між /oldestзапитом та коли deleteбуло видано.