[解決済み] REST HATEOAS（成熟度3）の有用性/重要性とは？

誰が気にしているか知っていますか？スクリーン スクレイピングされた Amazon 自動クライアントを書いたことのある人なら誰でも。Web トラフィックを嗅ぎつけ、HTML ページを読み、どのリンクをいつ、どのペイロードで呼び出すかを見つけるために苦労している人。

そして、Amazon が内部プロセスや URL 構造を変更するとすぐに、ハードコードされたクライアントは失敗しました -- リンクが壊れてしまったからです。

しかし、カジュアルなウェブ サーファーは、ほとんど支障なく一日中買い物をすることができました。

テキストベースのインターフェイスを解釈し、直感し、ショッピングカートの小さなグラフィックを認識し、それが実際に何を意味するのかを理解することができる人間によって、RESTは拡張されただけです。

ソフトウェアを書いている人のほとんどは、そのようなことはしません。自動化されたクライアントを書いている人のほとんどは、それを気にしません。ほとんどの人は、アプリケーションが最初に壊れないように設計するよりも、クライアントが壊れたときに修正する方が簡単だと考えています。ほとんどの人は、それが問題となるような十分なクライアントを持っていないだけなのです。

もしあなたが、トラフィックの両側で専門家の技術サポートとITがあり、変更を素早く、確実に、スケジュール通りに伝えることができる2つのシステム間で通信するために内部APIを書いているなら、RESTは何も買ってくれません。REST は必要なく、アプリは十分に大きくなく、重要なほど長寿でもありません。

大規模なユーザー ベースを持つ大規模なサイトでは、この問題があります。彼らは、自分たちのシステムと対話するときに、気まぐれでクライアント コードを変更するように人々に頼むことはできません。サーバーの開発スケジュールは、クライアントの開発スケジュールと同じではありません。API への突然の変更は、双方のトラフィックとオペレーションを混乱させるので、関係者全員にとって単に受け入れがたいものです。

ですから、そのような運用では、バージョンアップが容易で、古いクライアントが移行しやすく、後方互換性がないよりもある方が簡単なので、HATEOAS の恩恵を受ける可能性が非常に高いのです。

ワークフローの多くをサーバーに委ね、その結果に基づいて動作するクライアントは、そうでないクライアントよりもサーバーの変更に対してはるかに堅牢です。

しかし、ほとんどの人はそのような柔軟性を必要としません。彼らは 2、3 の部門のためにサーバー コードを書いており、それはすべて内部使用です。壊れたら修正し、それを通常の業務に組み込んでいるのです。

RESTであろうと何であろうと、柔軟性は複雑さを生みます。シンプルで高速にしたいのであれば、柔軟性を持たせるのではなく、「ただやるだけ」にしてしまいます。システムに抽象化と再参照を追加すると、より難しくなり、定型文が増え、テストするコードが増えます。

RESTの多くは、「必要ないだろう」という箇条書きに失敗します。もちろん、必要になるまでは。

もし必要なら、それを使い、その通りに使ってください。REST は、HTTP で前後にものを押し付けるものではありません。それよりもはるかに高いレベルなのです。

しかし、RESTが必要なとき、そしてRESTを使うとき、HATEOASは必需品です。それはパッケージの一部であり、それを機能させるための鍵なのです。

例：-。 これをよりよく理解するために、サーバーからID123のユーザーを取得する以下のレスポンスを見てみましょう ( http://localhost:8080/user/123 ):

{
    "name": "John Doe",
    "links": [{
            "rel": "self",
            "href": "http://localhost:8080/user/123"
        },
        {
            "rel": "posts",
            "href": "http://localhost:8080/user/123/post"
        },
        {
            "rel": "address",
            "href": "http://localhost:8080/user/123/address"
        }
    ]
}