最近、Mark Baker氏はgithub上のNokia REST APIプロジェクトについてtweetに書いた。
特に、文書化について次のように語る。
一番の利点はAPI自分自身がAPIドキュメントになることです。
- HATEOASなしで開発をする場合、開発者はドキュメントから次のリクエストをどう作るかを探す。
- HATEOASありの場合、開発者は次のアクションについて知ることができる。
CapGemini のSteve Jones氏は最 近のブログ記事でこれについてまとめた。
上記のいずれも私は好きではありません。
私はドキュメント化の熱烈な支持者であり、設計の支持者でもあります。
でも、設計をただの概念的な段階の一連を過程として扱い、唯一重要なのは次のステップであるという人達のファンではありません。
Steve氏は以前、ITの 価値は技術より思考力にあると信じていることを言及した。そして彼はそのNokiaの文書化事例からITにおいての思考と 設計がすでに死んている、もしくは死にかかっていることを指摘した。彼は人達が設計を大事にしないし、開発プロセスの中での比重がますます小さくなると 思っている。
明確になること、特に明確なドキュメント化は大事です。これはら以下の2つは弱くなるでしょう。
- サーバアプリケーションの完成を待たなくてもクライアント作成ができる
- ドキュメント化は迷路の先を見通すことができる唯一の方法である
Steve氏によると、特にRESTとHATEOASをめくっては設計よりコーディング優先開発が強いられる。
サービスに対してドキュメント化されたAPIを持つことによって設計者が計画を精密に立てることができるだけではなくサービスを実装する前に作業をどう進 めばいいのかが判る。
Steve氏は先述したRESTのAPIとコードそして擬似設計まで継続的に切り替えなければならない設計者のアプローチが役に立たないということが過言 ではないことを見せた。
彼の観点で見たこのような現在エンタプライズ開発のトレンドはIT発展の停滞とRESTや他のソリューションの維持補修性に影響を与えていると彼は述べ た。
実装の事前作業が足りないということは私がRESTに反対する理由の一部です。もしも私がクライアントとサービスを 分離しなければならないとしたら、私は'先クライアント,後サービス開発'をウォーターフォールプロジェクトで進みたくありません。つまり、私は人々が結 果を計画するのが好きです。
でも、Steve氏は実装のためにRESTを利用することに対しては反対しない。ただ、彼が見て最近のアプローチ（例えば、 NokiaAPI)は重要な設計段階では役に立たないし、彼らを巡 回セールスマン問題的なアプローチへ導くだけだ。
道を分からない場合、一番早く一度ずつめぐるルートは探し出せないことと同じく、単に次の段階がすぐ分かるend- to-end実装が効率的だとは思われません。
ある人はSteve氏のブログに以下のようなコメントを追加した。
私も似たようなことを公開API、REST、ライブラリなどから見ました。開発者は、彼らが行うすべての非常に短い サイクルでの（良い）アイデアを受け入れています。全ては繰り返されているし、いろんな理由で開発者は先行設計が重要ではないと思うし、むしろ悪いとまで 思います。APIの後ろで作業する場合、漸進的設計はより受け入れやすいです。でも、公開APIは公開後にも多かれ少なかれ修正が必要です。彼らはいくつ かの方法（例えば、拡張）で改善できるが、リファクタリングはユーザに非現実的な負担が掛かります。
Steve氏がRESTに合わせて必要な一つはRESTful APIドキュメント化練習と共に制限的実行で、他のコメンテーターが指摘したように、単にHATEOSに依存しないことだ。