Відсутність збереження стану (statelessness) в REST API

1. Відсутність збереження стану (statelessness) Відповідно до архітектури REST (REpresentational “State” Transfer) сервер не зберігає жодного стану про сеанс клієнта на стороні сервера. Це обмеження називається statelessness. Кожен запит від клієнта до сервера повинен містити всю необхідну інформацію для розуміння запиту. Сервер не може скористатися жодним збереженим контекстом на сервері. Тому стан сеансу програми повністю зберігається на клієнті. Клієнт самостійно несе відповідальність […]

Детальніше

Параметр “q” в HTTP заголовку “Accept”

1. Клієнти API підтримують кілька форматів REST API може повертати представлення ресурсу в багатьох форматах – точніше, MIME-типи . Клієнтська програма або браузер може запитувати будь-який підтримуваний тип MIME у заголовку HTTP Accept . Технічно Accept Header може мати кілька значень у формі значень, розділених комами. Наприклад, Accept Header із запитом text/html або application/xml формати можна встановити як: 2. Параметр “q”. Іноді клієнти можуть […]

Детальніше

Контроль версій REST API

Зміни в API неминучі, оскільки наші знання та досвід роботи з системою вдосконалюються. Управління впливом цієї зміни може бути досить складним, якщо вона загрожує порушити існуючи інтеграцію клієнтів. Щоб керувати проблематикою оновлень, версіюйте свій API. Контроль версій допомагає нам виконувати ітерацію швидше, коли потрібні зміни ідентифікуються в API. 1. Коли треба користувати версії? Оновлювати API потрібно лише […]

Детальніше

Узгодження вмісту в REST

1. Узгодження змісту Як правило, ресурси REST можуть мати кілька презентацій, головним чином через те, що можуть бути різні клієнти, які очікують різних представлень. Запит клієнта на відповідну презентацію називається переговорами щодо контенту . HTTP містить кілька механізмів для «узгодження вмісту» — процесу вибору найкращого представлення для даної відповіді, коли доступно кілька представлень.— RFC 2616 2. Узгодження вмісту, кероване сервером і […]

Детальніше

Посібник з іменування ресурсів REST

1. Що таке ресурс? У REST первинне представлення даних називається ресурсом . Наявність узгодженої та надійної стратегії іменування ресурсів REST стане одним із найкращих проектних рішень у довгостроковій перспективі. Ключовою абстракцією інформації в REST є ресурс. Будь-яка інформація, яку можна назвати, може бути ресурсом: документом або зображенням, тимчасовою службою (наприклад, «погода в Харкові зараз»), колекцією інших ресурсів, невіртуальним об’єктом (наприклад, людиною) […]

Детальніше

Ідемпотентність – або стійкість до постійного навантаження в однакових відповідях сервера

У контексті REST API, коли багато ідентичних запитів має той самий ефект, що й один запит, тоді такий REST API називається ідемпотентним. 1. Ідемпотентні API Коли ми розробляємо REST API, ми повинні усвідомлювати, що споживачі API можуть робити помилки. Споживачі можуть написати код клієнта таким чином, щоб до API могли надходити повторювані запити. Ці повторювані запити можуть бути ненавмисними, […]

Детальніше