JSON APIからHTMLを返しても大丈夫ですか？

現在のプロジェクトでは、JSONのみをサポートするものとして文書化されている、新しく作成されたRESTful APIの使用を伴うサービスの実装を担当しています。

クライアントは、一貫して「application / json」のacceptヘッダーと「application / json」のcontent-typeで要求を行います。ただし、一部のエンドポイントは、HTMLのコンテンツタイプ、さらにはHTML本文で応答を送信します。私にとってこれは明らかに間違ったアプローチであり、正当化することはできません。

プロジェクト全体を通して、この同じプラクティスが2つの異なるベンダーと2つの異なるサービスに適用されています。サービスを変更する必要がある理由を正当化する必要があることに気づきました。ベンダーは、クライアントはこれに対処する必要があると述べており、デフォルトの「箱から出して」これに対処しないため、選択したRESTライブラリでさえ疑問視されています（RestEasy）。

これはフラストレーションの大きなポイントでした。私の主張を裏付ける多くの参考文献を見つけることができません。これは、それが非常に明白であるので、ポイントが議論の余地があるからだと思います。

問題は、何かが足りないということですか？私はこれについて熱心ですか？このシナリオでcontent-typeのapplication / jsonを持たないJSON APIを使用しても大丈夫ですか？参照をいただければ幸いです。商業的な観点からこの状況をどのように解決しますか？

accept特定のメディアタイプを要求するヘッダーを送信している場合、サーバーは他の何かを返すべきではありません。200OKステータスコードを返すべきではありません。

Restpatterns.orgから：

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をサポートする場合としない場合があります排他的に。

良いの over HTTPを実行しているAPI（その文脈で、あなたがover HTTPを公開APIについて話していると仮定するのが妥当）さまざまな形式の要求内容にあなたを許可する必要があり、それらのフォーマットは（そしておそらく必要があります）HTMLを含めるだけでなく、することができますJSONとXML。どうして？まあそれはAPIを学ぶことをはるかに簡単にするでしょう、概念的にはそれはどんな目的などのためにインスタントブラウザベースのUXを提供します...

興味深い質問は、さまざまなコンテンツ形式をサポートするAPIが、クライアントがどの形式を期待しているかを知らずに呼び出された場合、どの形式を返す必要があるかということです。これは宗教的な議論に向かう傾向があります-しかし、HTMLはプロバイダーに有用な情報を含めるオプションを提供します（「コンテンツの受け入れヘッダーを設定することを忘れないでください」など）。

APIの質問に答えるために、落ち着いたものとjsonをサポートするものは、要求されたコンテンツであればHTMLを絶対に返すことができるはずです。

クライアントは、「application / json」のacceptヘッダーと「application / json」のcontent-typeで一貫して要求を行います

はい、これは正しいことですが、ベンダーが気にするわけではありません。JSONサービスは常にJSON応答を返すべきだと思うので、私はあなたの不満を完全に理解していますが、そうではない多くの例があります。

プロジェクト全体を通して、この同じプラクティスが2つの異なるベンダーと2つの異なるサービスに適用されています。サービスを変更する必要がある理由を正当化する必要があることに気づきました。ベンダーは、クライアントはこれに対処する必要があると述べており、デフォルトの「箱から出して」これに対処しないため、選択したRESTライブラリでさえ疑問視されています（RestEasy）。

さて、ベンダーに同意する必要があります。それは彼らのサービスであり、彼らがそれを使用するための特別なケースを明確に文書化する限り、あなたは彼らがそれを変更することを本当に課すことはできません。開発者が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。サーバーも誤って応答する可能性があります。多くのWordpress Webサイトがあり、ページが見つからないファイルに対して応答しtext/html、ステータスコード200を返します。

これが、サーバー側のすべての悪い習慣です。私があなたに伝えようとしているのは、それは絶対に可能であり、頻繁に起こるということです。これらのことを構成するとき、人々は何をしているのかわかりません。

参照をいただければ幸いです。商業的な観点からこの状況をどのように解決しますか？

いくつかのプロジェクトでこの問題に遭遇しました。あなたpostのサーバーへのJSONデータと、それはどちらかJSONまたはHTMLレスポンスを提供します。

応答にどのタイプが含まれているかを知ることは、たいしたことではありません。最初の文字がである{か、[JSONを想定できる場合。もしそうなら、<あなたはHTMLを仮定することができます。それは私が過去にそれを処理した方法です。APIを書いたプログラマーは、HTTPヘッダーについてすべて知っていることがあります。すべてがtext/html応答として返されます。運が良ければ、Apacheがデフォルトに設定されtext/plainていることがあります。

これらの問題は存在し、将来にわたって存在し続けます。サーバー間の通信は、規制されていないアクティビティです。悪いHTTP応答を与えるサーバーの組合からベンダーを追い出す統治体はありません。