たとえば、アイテムを取得するために GET を呼び出し、DELETE で削除して再度 GET すると、2 番目の GET はどのように機能するのでしょうか?
つまり、REST の原則に正しく従うということは、GET をキャッシュできるので、これを行うための正しいアプローチとは何でしょうか? REST で古いデータを処理するためのアプローチは何ですか?
たとえば、アイテムを取得するために GET を呼び出し、DELETE で削除して再度 GET すると、2 番目の GET はどのように機能するのでしょうか?
つまり、REST の原則に正しく従うということは、GET をキャッシュできるので、これを行うための正しいアプローチとは何でしょうか? REST で古いデータを処理するためのアプローチは何ですか?
まず、動作は、DELETE呼び出しが応答コードとして返したものによって異なります。
DELETEが返される場合、200 - OK
または204 - No Content
クライアントは404 - Not Found
GETへの次の呼び出しを開始する必要があります。これは、202と204は、リソースがすぐに削除されたことを意味するためです。
ただし、DELETEが返される場合202 - Accepted
、クライアントはその後しばらくの間、リソースを正常にGETできる可能性があります。これは、202はリソースに削除のマークが付けられていることを意味しますが、必ずしもすぐにクリーンアップされるとは限らないためです。
次に、キャッシュが含まれている場合、キャッシュが存在しない場合に発生する動作と一致するように動作を構築する必要があります。DELETEが成功すると、キャッシュされたコピーに加えて、データの実際のオリジンからも常に削除されます。
最初に述べたように、DELETE に続く GET は、適切なキャッシュに関係なく、HTTP 404 エラーを生成する必要があります。ロジック コードは、メモリ内ストアまたはキャッシュだけでなく、永続ストアからもレコードを削除できるほどスマートである必要があります。さらに、UI は、適切と思われるフローまたはプロセスで 404 の結果を処理できる必要があります。