指定したデータの取得に成功した、あるいはリクエストした処理が成功した場合には200番台のステータスコードを返す。

200　OK

最も多用されるステータスコード。リクエストが成功したことを示す。

201　Created

リクエストの結果サーバ側でデータ作成が行われた場合に返す。POSTが使われた場合に使用される。

ユーザー登録が行われてユーザーが追加された場合
TODOの項目の追加、画像アップロード
サーバー側に新しいファイルが作成される、データベースのテーブルに新しい項目が追加される場合

202　Accepted

リクエストした処理が非同期で行われ、処理は受け付けたけれど完了していない場合に利用される。
具体例として、ファイルの形式変換や、リモートノーティフィケーション（Apple Push NotificationやGoogle Cloud Messaging）の処理は時間がかかる場合が多く、全ての処理を終えてからクライアントに返すのではレスポンスまでの時間に非常に時間がかかってしまう。そこで一度クライアントにはレスポンスを返しておいて、サーバ側で非同期に処理を行う、という方法が取られる。

202は「処理は開始したけど、まだ終わっていませんよ」ということを通知する際に利用される。

LinkedInのグループディスカッションに投稿するAPIの場合、投稿が成功すると通常は201が返されるが、モデレータの承認を必要とする場合は、すなわちすぐに投稿が表示されないケースでは202が返される。
つまり広い意味で非同期だが、プログラム的には非同期ではないケースでも使用されている。

204　No Content

レスポンスが空の時に返す。多い利用例として、DELETEメソッドなどでデータの削除を行った際に204を返す。
それ以外にもPUTやPATCHでのデータ更新では、既存のデータを更新するだけなので204を返す方が自然という意見もあるようです。実際、SalesForceのAPIでは、PATCHリクエストでデータを更新した際に正しく更新されると204が返される。

一方で204はあまり使うべきではないという意見もあります。なぜならレスポンスが空であるということは情報が少なすぎて、その結果をどう解釈すれば良いのか分かりにくいというものです。
そしてPUTやPATCHでは変更された状態のデータを、DELETEでは削除されたデータそのものを返すべきだという主張です。