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