質問

私のREST APIはJSONを返します。

現在、MIMEタイプとしてtext / plainを返していますが、おかしいと感じています。 application / x-javascript または他のタイプを返す必要がありますか?

2番目の質問は、エラー状態のHTTPステータスコードに関するものです。 REST APIがエラー状態を返している場合、JSONとして返しています

{ result: "fail", errorcode: 1024, errormesg: "That sucked. Try again!" }

HTTPステータスコードを 200 OK のままにしておく必要がありますか?

役に立ちましたか?

解決

JSON 仕様は、 application / json を示唆しています。 IETF および IANA レジストリ。

2番目の質問では、メッセージ処理が何らかの方法で失敗した場合、構造化された標準エラー応答をJSONメッセージとして返す必要があると思います。何らかの理由でメッセージをバックエンドハンドラに配信できない場合にのみ、HTTPエラーコードを検討してください。

更新2014-06-27 :クライアント(ブラウザ)が200の応答でしか動作していなかった時代は昔からあり、RESTful APIの一般的なアドバイスは、応答に適したHTTP応答コードを使用することです、成功した応答の場合は2xx(PUTの場合は201作成、DELETEの場合は204のコンテンツなし)、API自体からのエラーを含むすべてのエラー状態の場合は4xxおよび5xx。

他のヒント

HTTPエラーステータスとアプリケーション固有のペイロードの両方で返信したい。

いいえ、エラー状態で200を返すべきではありません。

ステータスコードを繰り返しても、応答ペイロードに詳細なエラーコードを含めても構いません。

Content-type は application / json です。 rel = "noreferrer"> RFC 4627 。MIMEタイプIANAも登録します(実際、IANAのページに表示されます)。もちろん、クライアントを作成する場合は、受け入れる内容をよりリベラルにしたいだけでなく、 text / json text / x-json

今、エラーが発生した場合、HTTP 200を返さない必要がありますが、これは根本的に非RESTfulです。エラーに完全に一致しない場合があることはわかっていますが、 RFC 2616セクション10.4 -10.5、およびJSONでより正確に。

「REST API」による場合RESTアーキテクチャに従うことを意味する場合、使用するメディアタイプは、REST APIを通じて公開する機能によって決まります。新しいオブジェクトを作成できるようにしたいですか?オブジェクトのリストを照会しますか?オブジェクトを編集しますか?その場合、使用する適切なRESTfulメディアタイプは、vnd.collection + jsonです。これは、jsonオブジェクトのコレクションを操作するハイパーテキストリンクインターフェイスを定義しているためです。

注:RESTful APIはメディアタイプapplication / jsonを使用できますが、このメディアタイプにはハイパーテキストリンクRESTfulインターフェイスがないため、状態変更の終点になります。

また、HTTP RPC呼び出しがapplication / jsonオブジェクトを返し、他のHTTP RPC呼び出しがそれらのオブジェクトを操作するWeb APIアーキテクチャに従うことも完全に受け入れられます。また、状態の変更を使用およびナビゲートするためのハイパーテキストリンクインターフェイスはありません。しかし、これはRESTではありません。

このRESTの説明が好きです(RESTの作成者から):

REST APIはハイパーテキスト駆動でなければなりません

  

言い換えると、アプリケーションの状態のエンジン(したがってAPI)   ハイパーテキストによって駆動されていない場合、RESTfulにすることはできず、   REST APIであること。期間。

また、その投稿の議論からRESTfulアプリケーションのこの例があります: Lost BoysのSpam-E RESTアプリケーション

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top