WebAPI トレーニング 05 -エンドポイント設計編-

エンドポイントとホスト名の設計

よくある例

http://api.fugahoge.com/v1
http://api-public.ikatako.com/v2

ホスト名にプラス、v1やv2といった数値が入っていることが結構ある。
これは API自体のバージョンを表す もの。

あとは api という単語をホスト名に入れておくことで、DNSレベルで分けられて自サーバ側で管理しやすいというのもあるっぽい。

api-public のように、オープン／パブリックなAPIであることを明示しておいて、 BtoCとBtoBで、エンドポイントを変えて可視性の段階を設けるのもありっぽい。
こっちはBtoC（第三者利用可能）用、あっちはBtoB（提携企業向け）用、って分けると分かり易いかも。

何がいいかは、その都度の状況と背景を考慮して最適化するのがよろしそう。

HATEOASとは、を、結論から簡単に言えば、こんな感じなのかな。
最初に叩いたAPIから、次に起こせる行動のためのURIをリンクとして含める ようなAPIって感じかな。

最初にAPIを叩いたら、数珠式に叩くであろうAPIのURIをあらかじめ仕込んでおくことで、API利用者側は具体的なURIや必要なパラメータを意識することなく、APIを簡単に利用することができる。

それがHATEOASという考え方であり、設計レベルでいえば０〜３まであるうちの、最高の３らしい。

ちなみにLevel0から3までの区分はこんな感じ

で、上記のことを提唱したのが、「Roy Fieldingの論文」らしい。
自分の意識が最高を超えたら読もう。。

HATEOASは、 hypermedia as the engine of application state
の略。
アプリケーションが持つ状態のエンジンとしてのハイパーメディア？？

クライアントがURIを知ることが、最初の導線以外知る必要ないので、 URIの変更がしやすくなるのと、 改造しやすい(Hackable) である必要がない
スマホアプリの開発では、最初の導線のみハードコーディングにすることで、内部では動的にURIを利用できるから、仕様の変更に強いアプリにすることができる。 （いちいちアップデートする必要がない！！！！）
URIの間違いに起因するバグを減らせる（動的にURIを利用できるから

たしかに。

まぁただ、その分、サーバ側からJSONとかレスポンス返す時にそういう配慮が必要になってきそうで、ちょっとバックエンド側のコストが高くなりそうやな・・・

-エンドポイント設計編- はこれにて終了！
クライアント側の設計方法を知ったので、今度はサーバ側の設計方法（レスポンスについて）勉強していきまーすっ！！