データ連携が必要になったらRESTを開発すればいいという考えは、常々違和を感じている。
一定規模以上の組織で運用される前提のシステムは、将来どんなシステムと連携するのかわからない状態でも最初からリソース志向・RESTfulな設計思想で作るべきだ。
現場では、RESTという単語はもはやRESTfulAPIを指している場合が多く、APIに代わる単語として使われているきらいがある。
公開するかどうかわからないリソースであってもRESTfulで作ることは、APIエコノミーが当然になった今では当たり前のことだ。難しい話は1つもないのだが、なかなかどうして。
一度でも自分でウェブサービス・ウェブシステムを作ったことがあればわかるが、最初からリソース志向・ステートレスで作っておかないと、途中の段でAPIを作るってのはしんどい。サーバサイドにセッションやコンテキストを大量に管理するようなシステムでは、特にAPIの認可周りの実装で地獄を見る。
それでもいいというなら咎めはしないが、こうして乱立する独自の設計思想のシステム達は最終的に遺産みたいになって、誰が作ったの?的な扱いになりがち。
たとえるなら電話とチャットのようなもので、今後も多くのシステムを刷新していくことになるわけだが、各々のシステムがグループチャットみたいな非同期的で長期的にゆるいつながりを持ち続けられるようにしたいと思っているところを、そういうなかでステートフルなシステムが1つでもあると、電話に付き合わないといけないといった、そんな感じ。電話機能しかないのに、必要に応じてチャットできるようにしますと言われても、最初からチャットできるようにしておいてーと思わざるをえない。