これはあまり技術的な質問ではなく、主題についての考察です。
REST は、HTTP プロトコルを使用してリソースを提供する優れた方法を民主化し、開発者がリソースとユーザー インターフェイスを分割することで最もクリーンなプロジェクトを実行できるようにしました (バックエンドは現在、REST API を使用するバックエンドのみを実際に扱っています)。
これらの API については、ほとんどの場合、GET、PUT/PATCH (うーん?)、POST、および DELETE を使用しますが、どちらも CRUD データベースを模倣しています。
しかし、プロジェクトに費やす時間が経つにつれて、多くの優れた機能を追加することで UX を改善できると感じています。たとえば、ユーザーがリソースを削除することを恐れる理由は何でしょうか? 回復システムを設置しないのはなぜですか (Google Keep アプリで見られるように、削除を元に戻すことができます。これは、UX の点で素晴らしいと思います)。
意図しない削除を防ぐ方法の 1 つは、リソースを表すテーブル内の列を使用することです。たとえば、本を削除しようとしているので、削除ボタンをクリックすると、データベースでこの行に「deleted = TRUE」というフラグのみが付けられ、リソースのリストを参照するときに削除された行が表示されなくなります (GET)。 .
これは、DELETE と DESTROY の "メソッド" の間に区別がないため、私たちの大切な REST パターンと競合します。
私が言いたいのは、REST を私たちの UX ニーズに合わせて進化させること、つまり HTTP プロトコルも進化させることを考えるべきか、それとも純粋なリソース管理としてとどまり、代わりに HTTP プロトコルを気にせず従うべきかということです。回避策を使用してそれに適応するだけです（ソフト削除にPATCHを使用するなど）？
個人的には、リソースを可能な限り適切に認定しようとしているため、少なくとも 4 つの新しいプロトコルを確認したいと考えています。
- DELETEは、他のメソッドが影響を与えるのを防ぐ方法になります
- このリソースの痕跡を完全に削除することで、 DESTROYはより劇的になります。
- RECOVERは、他のメソッドに対して「こんにちは、彼は戻ってきます。お楽しみに」と言う方法です。
- TRASHは GET に似ていますが、DELETED リソースのみを対象としています
それについて考えさせられたのは、このリソースの動作に対処するためのクリーンな REST ソリューションの研究です。私はいくつかのウェブサイトの投稿を見てきました
- https://www.pandastrike.com/posts/20161004-soft-deletes-http-api
- https://philsturgeon.uk/rest/2014/05/25/restful-deletions-restorations-and-revisions/
- ...
PUT または PATCH を使用してソフト削除を使用可能にするようにというアドバイスですが、それは正しくないように思えますね。
この問題についての私の考え:
- 新しい HTTP メソッドの提案と以前のメソッドの更新との間に大きなステップはありますか (HTTP/2 が話題になっていると聞きました。
- Web 開発領域の外では意味がありますか? この変更は、私たちの他のドメインに影響を与える可能性がありますか?