1. Узгодження змісту
Як правило, ресурси REST можуть мати кілька презентацій, головним чином через те, що можуть бути різні клієнти, які очікують різних представлень. Запит клієнта на відповідну презентацію називається переговорами щодо контенту .
HTTP містить кілька механізмів для «узгодження вмісту» — процесу вибору найкращого представлення для даної відповіді, коли доступно кілька представлень.— RFC 2616
2. Узгодження вмісту, кероване сервером і агентом
Якщо вибір найкращого представлення для відповіді виконується алгоритмом, розташованим на сервері, це називається узгодженням, керованим сервером . Якщо цей вибір здійснюється на стороні агента або клієнта, це називається узгодженням, керованим агентом .
На практиці ми НЕ знайдемо багато використання переговорів на стороні сервера, тому що таким чином нам доведеться робити багато припущень щодо очікувань клієнта.
Кілька речей, наприклад контекст клієнта або те, як клієнт використовуватиме представлення ресурсу, визначити майже неможливо. Крім того, кероване сервером узгодження робить серверний код більш складним, без потреби.
Отже, більшість реалізацій REST API покладаються на узгодження вмісту, кероване агентом. Узгодження вмісту, кероване агентом, залежить від використання заголовків HTTP-запитів або шаблонів URI ресурсу .
2.1. Використання заголовків HTTP
На стороні сервера до вхідного запиту може бути прикріплена сутність. Щоб визначити його тип, сервер використовує заголовок HTTP-запиту Content-Type. Деякі поширені приклади типів вмісту: «text/plain», «application/xml», «text/html», «application/json», «image/gif» і «image/jpeg».
Content-Type: application/json
Так само, щоб визначити, який тип представлення потрібний на стороні клієнта, використовується заголовок HTTP Accept. Він матиме одне зі значень, згаданих Content-Type вище.
Accept: application/json
Зазвичай, якщо Accept в запиті немає заголовка, сервер може надіслати попередньо налаштований тип представлення за замовчуванням .
Впровадження Accept узгодження вмісту на основі заголовка є найбільш використовуваним і рекомендованим способом.
2.2. Використання шаблонів URL-адрес
Інший спосіб передачі інформації про тип вмісту на сервер, клієнт може використовувати конкретне розширення в URI ресурсу. Наприклад, клієнт може запитати деталі за допомогою:
http://rest.api.com/v1/employees/20423.xml http://rest.api.com/v1/employees/20423.json
У наведеному вище випадку URI першого запиту поверне відповідь XML, незалежно від того, URI другого запиту поверне відповідь JSON.
3. Визначення налаштувань
Можна мати декілька значень у Accept заголовку, використовуючи параметр «q», тобто відносний коефіцієнт якості .
Клієнт може захотіти надати кілька значень у заголовку accept, якщо клієнт не впевнений, чи присутній його потрібне представлення чи підтримується сервером у цей час. [ RFC 2296 ]
Наприклад,
Accept: application/json,application/xml;q=0.9,*/*;q=0.8
Наведений вище заголовок Accept дозволяє запитувати у сервера формат JSON (перший вибір). Якщо він не може, можливо, він може повернути формат XML (другий варіант). Якщо це все ще неможливо, нехай повертає те, що може.
Порядок переваг визначається через параметр q зі значеннями від 0 до 1. Якщо нічого не вказано, неявне значення за замовчуванням дорівнює 1.