У контексті REST API, коли багато ідентичних запитів має той самий ефект, що й один запит, тоді такий REST API називається ідемпотентним. 1. Ідемпотентні API Коли ми розробляємо REST API, ми повинні усвідомлювати, що споживачі API можуть робити помилки. Споживачі можуть написати код клієнта таким чином, щоб до API могли надходити повторювані запити. Ці повторювані запити можуть бути ненавмисними, […]
Узгодження вмісту в REST
1. Узгодження змісту Як правило, ресурси REST можуть мати кілька презентацій, головним чином через те, що можуть бути різні клієнти, які очікують різних представлень. Запит клієнта на відповідну презентацію називається переговорами щодо контенту . HTTP містить кілька механізмів для «узгодження вмісту» — процесу вибору найкращого представлення для даної відповіді, коли доступно кілька представлень.— RFC 2616 2. Узгодження вмісту, кероване сервером і […]
Відсутність збереження стану (statelessness) в REST API
1. Відсутність збереження стану (statelessness) Відповідно до архітектури REST (REpresentational “State” Transfer) сервер не зберігає жодного стану про сеанс клієнта на стороні сервера. Це обмеження називається statelessness. Кожен запит від клієнта до сервера повинен містити всю необхідну інформацію для розуміння запиту. Сервер не може скористатися жодним збереженим контекстом на сервері. Тому стан сеансу програми повністю зберігається на клієнті. Клієнт самостійно несе відповідальність […]
Коди стану HTTP
API REST використовують частину рядка стану повідомлення HTTP-відповіді, щоб повідомити клієнтів про загальний результат їхнього запиту. RFC 2616 визначає синтаксис рядка стану, як показано нижче: Рядок статусу = HTTP-версія SP Код стану SP Reason-Phrase CRLF HTTP визначає ці стандартні коди стану, які можна використовувати для передачі результатів запиту клієнта. Коди стану поділяються на п’ять категорій. 1xx Коди статусу [Інформаційні] Код статусу Опис […]
Кешування відповіді REST API
1. Кешування Кешування — це можливість зберігати копії даних, до яких часто звертаються, у кількох місцях на шляху запит-відповідь. Коли споживач запитує представлення ресурсу, запит проходить через кеш або серію кешів (локальний кеш, кеш-проксі-кеш або зворотний проксі-сервер) до служби, на якій розміщено ресурс. Якщо будь-який із кешів уздовж шляху запиту має свіжу копію запитаного представлення, він […]
Контроль версій REST API
Зміни в API неминучі, оскільки наші знання та досвід роботи з системою вдосконалюються. Управління впливом цієї зміни може бути досить складним, якщо вона загрожує порушити існуючи інтеграцію клієнтів. Щоб керувати проблематикою оновлень, версіюйте свій API. Контроль версій допомагає нам виконувати ітерацію швидше, коли потрібні зміни ідентифікуються в API. 1. Коли треба користувати версії? Оновлювати API потрібно лише […]