Клієнт послідовно робить запити із заголовком акцепту "application / json" та типом вмісту "application / json"
Так, це правильно робити, але це не означає, що постачальник дбає. Хоча я повністю розумію ваше розчарування, тому що я також вважаю, що служба JSON завжди повинна відповідати JSON, але є багато прикладів, коли це не так.
Протягом проекту ця сама практика застосовувалася у двох різних постачальників та двох різних служб. Мені довелося виправдовувати, чому послуги потрібно змінити. Постачальники заявили, що клієнт повинен впоратися з цим, і навіть моя бібліотека REST на вибір була поставлена під сумнів (RestEasy), тому що він не справляється з цим за замовчуванням "з коробки".
Ну, я маю погодитися з продавцем. Це їхня послуга, і якщо вони чітко документують особливі випадки її використання, то ви не можете дійсно нав'язувати їх зміні. Для них це недолік, оскільки розробники будуть повільно приймати API, і якби вони слухали, що потрібно розробникам, вони б це змінили, але, на жаль, немає правила, що вони повинні дотримуватися стандартів.
Питання: я щось пропускаю?
Запити заголовків нічого не означають, якщо вони не будуть перервані правильно на іншому кінці. Я знаю, що якщо я розробляю веб-API за допомогою PHP, то до біса з заголовками запитів. Я можу відповісти чим завгодно. Тоді як служба, сконфігурована в IIS з C #, пропонує набагато простіше обробляти заголовки запитів, їх тип та обробляти тип відповіді. Це має багато спільного з інструментами, які постачальник використовував для створення API.
Я з цього приводу будучи педантичним?
Так і ні. У мене є друзі розробника, які не зможуть пройти повз це. Вони стають настільки виправленими проблемою і не зможуть приступити до виконання інших завдань, поки API не працює так, як вони очікують, що він працює. Тепер це педантично.
Це проблема, оскільки постачальник створив "більше роботи" для виконання ваших завдань. Хтось би це засмутив. Я знаю, що був би.
Чи нормально мати JSON API, який не містить типу вмісту програми / json у цьому сценарії?
Абсолютно, але це не є хорошою практикою.
Клієнт може лише повідомити серверу, що таке тип контексту request. Він не має можливості застосовувати тип вмісту для response. Клієнт може лише повідомити сервер, що він буде acceptзібрати можливі типи вмісту.
Визначення поля заголовка
Поле Прийняття заголовка запиту може використовуватися для визначення певних типів носія, прийнятних для відповіді. Заголовки акцепту можуть бути використані для вказівки, що запит спеціально обмежений невеликим набором бажаних типів, як у випадку запиту на рядкове зображення.
Клієнт може запросити зображення image/jpeg, але відповіді сервера text/htmlта код статусу, 404якщо зображення не було знайдено. Сервери також можуть відповідати неправильно. Існує багато веб-сайтів Wordpress, які відповідають text/htmlі коду статусу 200для файлів, які не знайдені.
Тепер це вся практика BAD з боку сервера. Я намагаюся сказати вам, що це абсолютно можливо, і трапляється часто. Люди не знають, що вони роблять, коли вони налаштовують ці речі.
Посилання будуть вдячні. Як ви вирішуєте цю ситуацію з комерційної точки зору?
Я зіткнувся з цією проблемою в кількох проектах. Ви postпередаєте дані JSON на сервер, і він повертає або відповідь JSON, або HTML.
Дізнатися, який тип відповіді був насправді, не так вже й багато. Якщо перший символ є {або [ви можете припустити JSON. Якщо це, <ви можете припустити HTML. Ось як я впорався з цим у минулому. Іноді програміст, який написав API, знає джек про заголовки HTTP. Все повертається як text/htmlвідповіді. Якщо вам пощастило, у них Apache налаштований за замовчуванням, до text/plainякого іноді може допомогти.
Ці проблеми існують і будуть існувати далеко в майбутньому. Зв'язок між сервером та сервером - це далеко не регульована діяльність. Немає керівного органу, який би вигнав постачальника з профспілки на сервер, який дає погані відповіді HTTP.