JSON APIからHTMLを返すことはできますか？
私の現在のプロジェクトでは、JSONのみをサポートするものとして文書化されている、新しく作成されたRESTful APIの使用を含むサービスの実装を担当しています。
クライアントは一貫して、 'application/json'のAcceptヘッダーと 'application/json'のコンテンツタイプを使用してリクエストを行います。ただし、一部のエンドポイントは、HTMLの本文タイプでさえ、コンテンツタイプがHTMLの応答を送信します。私にとってこれは明らかに間違ったアプローチであり、正当化することはできません。
プロジェクト全体を通じて、これと同じ方法が2つの異なるベンダーと2つの異なるサービスに適用されています。サービスを変更する必要がある理由を正当化する必要があることに気づきました。ベンダーは、クライアントがこれに対処する必要があると述べ、選択した私のRESTライブラリでさえ、デフォルトでは「箱から出して」対応していないため、質問されました（RestEasy）。
これはフラストレーションの主要なポイントでした。私の主張を裏付けるための多くの参考文献を見つけることができません。これは、ポイントが非常に明白であるので、ポイントが根拠がないためだと思います。
問題は、何か不足しているのですか？私はこれについて知識を持っていますか？このシナリオでcontent-typeがapplication/jsonでないJSON APIがあっても問題ありませんか？参考文献をいただければ幸いです。商業的な観点からこの状況をどのように解決しますか？
特定のメディアタイプをリクエストするacceptヘッダーを送信する場合、サーバーは何か他のものを送信してはならず、200 OKステータスコードを送信してはいけません。
Acceptヘッダーフィールドが存在しない場合、クライアントはすべてのメディアタイプを受け入れると見なされます。 Acceptヘッダーフィールドが存在し、サーバーが結合されたAcceptフィールド値に従って受け入れ可能な応答を送信できない場合、サーバーは406（受け入れられない）応答を送信する必要があります
（エンファシス鉱山）
Restpatterns.orgは、これを実際のHTTP標準から取得します。 ヘッダーフィールドの定義-Accept
簡単に言うと、あなたは独断的ではありません。 Acceptヘッダーが明確にapplication/jsonを返すように指示している場合にサービスがHTMLを返す場合、サービスはHTTP標準に従っていません。
「RESTful JSON API」とはどういう意味ですか-ここでの最初の問題は、概念を混同しているということです（または、「サプライヤー」で技術担当者との間に誰かがいる可能性があります）。
RESTful API（あなたが本当にレベル1でまったく休んでいないのか、レベル3以上で何かを話しているのかに関わらずcf http://martinfowler.com/articles/richardsonMaturityModel.html ）は方法についてですAPIとやり取りするのは、送受信されるコンテンツの形式ではありません。プロトコルやトランスポートメカニズムについてもそうではありません...
同様に、JSON APIは、データ形式としてのJSONの使用をサポートするAPIです。休息する場合としない場合があり、HTTPを使用して実装される場合とされない場合があり、これが重要な点ですまたはJSONのみをサポートしていない可能性があります。
goodAPIをHTTP経由で実行すると（コンテキストでHTTP経由で公開されているAPIについて話していると想定するのが妥当です）、コンテンツをリクエストできます。さまざまな形式とそれらの形式には、HTML、JSON、XMLを含めることができます（おそらく含める必要があります）。どうして？まあ、それはAPIの学習をはるかに簡単にします。概念的には、あらゆる目的のためにインスタントブラウザベースのUXを提供します...
興味深い質問は、さまざまなコンテンツ形式をサポートする私のAPIが、クライアントがどの形式を期待し、どの形式を返すかを知らされずに呼び出された場合に発生します...？これは宗教的な議論になりがちですが、HTMLはプロバイダーに役立つ情報を含めるオプションを提供します（「コンテンツのAcceptヘッダーを設定することを忘れないでください」など）。
APIの質問に答えるために、それが要求されたコンテンツである場合、落ち着いたAPIとjsonをサポートするAPIは、HTMLを完全に返すことができる必要があります。
クライアントは一貫して、 'application/json'のAcceptヘッダーと 'application/json'のコンテンツタイプを使用してリクエストを行います。
はい、これは正しいことですが、ベンダーが気にかけるという意味ではありません。あなたの不満を完全に理解していますが、JSONサービスは常にJSON応答を返す必要があると思いますが、そうではない例がたくさんあります。
プロジェクト全体を通じて、これと同じ方法が2つの異なるベンダーと2つの異なるサービスに適用されています。サービスを変更する必要がある理由を正当化する必要があることに気づきました。ベンダーは、クライアントがこれに対処する必要があると述べ、選択した私のRESTライブラリでさえ、デフォルトでは「箱から出して」対応していないため、質問されました（RestEasy）。
まあ、私はベンダーに同意する必要があります。それは彼らのサービスであり、彼らがそれを使用するための特別なケースを明確に文書化している限り、あなたは彼らがそれを変更することを本当に強制することはできません。開発者がAPIを採用するのが遅く、開発者が必要とするものに耳を傾けると、APIを変更するため、これは彼らにとって不利です。しかし残念ながら、標準に従う必要があるというルールはありません。
問題は、何か不足していることですか？
リクエストヘッダーは、相手側で正しく中断されない限り、何も意味しません。 PHPを使用してWeb APIを開発する場合、リクエストヘッダーを使用することはわかっています。何でもやりたいことができる。一方、C＃を使用してIISで構成されたサービスは、要求ヘッダー、そのタイプ、および応答タイプの処理をはるかに容易にします。これは、ベンダーがAPIの構築に使用したツールに大きく関係しています。
私はこれについて知識を失っていますか？
はい、いいえ。私はこれを乗り越えられない開発者の友達がいます。 APIが期待どおりに機能するまで、問題に固執し、他のタスクを続行できなくなります。今、それは教訓的です。
ベンダーがタスクを完了するために「より多くの作業」を作成したため、これは問題です。誰もがそれにイライラするでしょう。私はそうなるでしょう。
このシナリオでcontent-typeがapplication/jsonでないJSON APIがあっても問題ありませんか？
もちろん、それは良い習慣ではありません。
クライアントは、requestのコンテキストタイプが何であるかをサーバーに通知するだけです。 responseのコンテンツタイプを強制する機能はありません。クライアントは、可能なコンテンツタイプのコレクションをacceptすることのみをサーバーに通知できます。
Accept request-headerフィールドを使用して、応答に受け入れられる特定のメディアタイプを指定できます。 Acceptヘッダーを使用して、インライン画像のリクエストの場合と同様に、リクエストが特定のタイプの小さなセットに限定されていることを示すことができます。
クライアントがimage/jpegの画像をリクエストすることは可能ですが、画像が見つからなかった場合、サーバーはtext/htmlとステータスコード404で応答します。サーバーが正しく応答しないこともあります。ファイルが見つからないページに対してtext/htmlおよびステータスコード200で応答するWordpress Webサイトは多数あります。
これで、サーバー側で[〜＃〜] bad [〜＃〜]の練習がすべて終わりました。私が伝えようとしていることは、それは絶対に可能であり、頻繁に発生するということです。これらの設定を行うときに、人々は自分が何をしているかを知りません。
参考文献をいただければ幸いです。商業的な観点からこの状況をどのように解決しますか？
いくつかのプロジェクトでこの問題に遭遇しました。サーバーにpost JSONデータを送信すると、JSONまたはHTML応答が返されます。
応答にどのタイプがあったかを知ることは、たいしたことではありません。最初の文字が{または[の場合、JSONであると想定できます。 <の場合は、HTMLと見なすことができます。それは私が過去にそれを扱った方法です。 APIを作成したプログラマーは、HTTPヘッダーについてすべて知っていることがあります。すべてがtext/html応答として返されます。運が良ければ、Apacheがデフォルトでtext/plainに設定されているため、役立つことがあります。
これらの問題は存在し、遠くまで存在し続けます。サーバー間の通信は、明らかに規制されていない活動です。悪いHTTP応答を与えるサーバーの組合からベンダーを追い出す統治機関はありません。