REST API: користувацькі заголовки HTTP проти параметрів URL

96

Коли ви використовуєте власні заголовки HTTP у частині запиту REST API?

Приклад:

Чи могли б ви коли-небудь використовувати

GET /orders/view 
(custom HTTP header) CLIENT_ID: 23

замість

GET /orders/view/client_id/23 or 
GET /orders/view/?client_id=23

http rest

— Василь Котовану
джерело

123

URL-адреса вказує на сам ресурс. А «клієнт» є ресурсом , який можна впливати, так повинно бути частиною базового URL: /orders/view/client/23.

Параметри - саме це, щоб параметризувати доступ до ресурсу. Це особливо вступає в гру зі стовпчиками та пошуки: /orders/find?q=blahblah&sort=foo. Там тонка грань між параметрами і суб-ресурсів: /orders/view/client/23/active versus /orders/view/client/23?show=active. Для пошуку я рекомендую стиль підресурсу та параметри резерву.

Оскільки кожна кінцева точка репрезентує перенесення стану (для маніпуляції мнемонікою), користувацькі заголовки слід використовувати лише для речей, які не включають ім'я ресурсу (url), стан ресурсу (тіло) або параметри безпосередньо впливає на ресурс (параметри). Це залишає справжні метадані про запит на власні заголовки.

HTTP має дуже широкий вибір заголовків, які охоплюють майже все, що вам потрібно. Там, де я бачив власні заголовки, з’являється система для системного запиту, що працює від імені користувача. Проксі-система перевірить користувача та додасть " X-User: userid" до заголовків та використає системні облікові дані для досягнення кінцевої точки. Система, що отримує, перевіряє, що облікові дані системи мають дозвіл діяти від імені користувача, а потім перевіряє, що користувач уповноважений виконувати дію.

— Ньяльскорва
джерело

Дякую за таку вичерпну відповідь! Ви все-таки використовували б X-User для мобільного API, де ризик мати злий проксі (який зачищає заголовок) все ще високий?

— Василь Котовану

1

Ні, використання X-User, про яке я згадав, є в системі для системних з’єднань, де система діє від імені третьої сторони. Наприклад, користувач U розмовляє з сервером А. Сервер A представляє облікові дані серверу B із заголовком X-User, щоб сказати «Використовуйте мої облікові дані, щоб перевірити, чи я уповноважений виконувати цю дію від імені користувача U». Це виникає в сервісно-орієнтованих архітектурах, і зазвичай ви використовуєте HTTPS. Мобільною платформою майже завжди повинен бути сам Користувач та використовувати відповідні облікові дані від першої особи для транзакції.

— Nialscorva

7

Третій абзац є однією з найбільш інформативних відповідей, які я читав на SO ;-)

— Alistair77

1

@Nialscorva Чудове пояснення! що, якби я хотів, щоб користувач взаємодіяв з моїм API через авторизований контейнер (наприклад, мій мобільний додаток)? Зараз я роблю те, що мій мобільний додаток не має права самостійно виконувати будь-які дії, а також кінцевий користувач .. обидва облікові дані повинні бути присутніми, якщо користувач бажає виконати дію.

— bolbol

6

Спеціальні заголовки мають наступні переваги:

Легко читаються мережевими інструментами / сценаріями (автентифікація, метаінформація, ...)
Зберігає URL-адреси без захисних матеріалів (безпечніше, не в кешах браузера / проксі-сервера)
Зберігає URL-адреси чистішими: дозволяє покращити кешування ресурсів

— Крістоф Руссі
джерело

їх також можуть мовчки позбавити / відфільтрувати довірені особи

— fusi

@fusi хороший момент ... ось тема про це: stackoverflow.com/questions/20820572/…

— Крістоф Руссі

5

Я використовував би спеціальний заголовок лише тоді, коли немає іншого способу передавати інформацію за стандартом чи за домовленістю. Darren102 пояснює типовий спосіб передачі цього значення. Ваш Api буде набагато більш доброзичливим, використовуючи типові візерунки з використанням користувацьких заголовків. Це не означає, що у вас не буде випадку використовувати їх, просто вони повинні бути крайнім засобом і чимось, що ще не обробляється специфікацією HTTP.

— позов
джерело

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

— Алессандро Сантіні

5

Коли ви використовуєте ... заголовки HTTP у частині запиту REST API?

Аутентифікація: GUID, базова автентифікація, власні маркери тощо, наприклад, Базова автентифікація з маркером Guid для REST api замість імені користувача / пароля

Якщо ви берете участь у передачі токенів або іншої інформації, схожої на автентифікацію, між доменами, охопленими PCI-DSS або іншими правилами безпеки, вам також може знадобитися поховати параметри, оскільки деякі правила прямо вимагають, щоб елементи автентифікації не потрапляли в URL-адреси, які можуть бути тривіально відтворені (з історії браузера, журнали проксі тощо).

— користувач3038458
джерело

1

Не існує стандарту для REST, проте прийнятим був би такий спосіб

GET /orders/view/23

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

— darren102
джерело

1

Я б не використовував власні заголовки, оскільки ви не знаєте, чи передадуть їх будь-які проксі. На основі URL-адреси - це шлях.

GET / orders / view / client / 23

— Ентоні Скотт
джерело

1

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

— Джуліан Решке

1

Безумовно, добре:

GET /orders/view/client_id/23 or 
GET /orders/view/?client_id=23

Також добре:

GET /orders/view/23 or

Я думаю, це теж буде нормально:

POST /orders/view 
(custom HTTP header) CLIENT_ID: 23

— paulsm4
джерело

REST-повною відповіддю POST має бути HTTP 303 із заголовком Location, встановленим приблизно на зразок "/ orders / view / 23".

— Rich Remer

0

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

— Анвар Хусейн
джерело