JSONを使用している場合は、JSONを返します。 XMLを使用している場合は、XMLを返します。フォームエンコードされたデータを受け入れる要求（ "application/x-www-form-urlencoded"）に対して、フォームエンコードされたデータを返すことは容認できますか？RESTサービスは入力コンテンツタイプを使用して応答する必要がありますか？
また、エラーの場合、ほとんどの実装は何をしていますか？テーマにはさまざまなバリエーションがあります。
フォームエンコードされたデータを返すことは、ひどいアプローチではありませんが、野生では見たことがないものです。最も一般的なフォーマットに従うことをお勧めします。ほとんどのAPIは、リクエストで何も指定されていない場合、送信するデフォルトの形式（通常はXMLまたはJSON）を選択します。
エラーに関しては、RESTの主な原則はHTTPがすでに提供しているメソッドを使用しているため、最初に適切なエラーステータスコード（400s and 500s）を応答本体に返します。
それが応答のような単純なものでしたエラーの体のための標準フォーマットはありません：
{ "stat" : "fail",
"code" : "97",
"message" : "Missing signature"
}
：Flickr年代のように、
{ "error" : "Invalid articled ID" }
..orより複雑に。 。およびそのXML相当：
<?xml version="1.0" encoding="utf-8" ?>
<rsp stat="fail">
<err code="97" msg="Missing signature" />
</rsp>
明らかに、APIを使用している開発者は、より冗長なエラーメッセージを感謝します。主に、APIの一貫性を求める必要があると思います。Messageという名前のパラメータがある場所にある場合は、別の場所にmessageという名前のパラメータがありません。
は、私は上記の失言をしたが、パイプ（|）として結果を返されたXMLで囲まれたデータを分離するだけでなく、実際のサードパーティの生産APIを扱ってきました。値のリテラルパイプは別のパイプ（||）によってエスケープされました。私はあなたが想像していたより複雑な問題を残しておきます。とにかく道徳的なのは、開発者が既に慣れ親しんだ構造とテクニックを使用することです。それ以上のものはと一致するようにしてください。
いいえ、理由はありません。
しかし、クライアントは、は、Accept：ヘッダーで特定の形式を要求できます。サーバがフォーマットをサポートしていない場合は、406 Not Acceptableを返します。 Accept：ヘッダーがまったくない場合や、クライアントがフォールバックとして*を使用している場合、サーバーはデフォルトを選択できます。
Cool。フォームエンコードされたデータを返送するのは間違っていました。解明のため：リクエストでフォームエンコードされたデータをサポートしている場合、レスポンスにJSONまたはXMLを返すのは意味がありますか？ –
それが文書化されている限り、私には意味があります。 –
私にとって素晴らしいサウンドです！ JSONの周りに構築したいと思っていますが、レガシーの呼び出し元はフォームエンコードされたPOSTをサポートしたいと考えています。このアドバイスによって、私たちはニーズを満たすことができます。ありがとうございました！ –