RESTについても共通認識にしよう。

↓でマイクロサービスについて書いたので、おまけでRESTについてもお話しよう。

　

　

　

RESTっていうのはAPIを作るときの設計原則(ルール)のこと
　

　

　

　

簡単に言うと、

・APIどういう風な名前にするべきか
・どういう風に結果をやりとりさせるか
・どうやって操作させるか

っていうあたりの設計原則
　
　
　
　

もう少し詳しく

・APIの名前に動詞を使用しない(api.craete.comなどはNG。api.userdata.comみたいな感じはイケてる)

　
・どのような操作を行うかはHTTPメソッドで指定する(GETなら取得、POSTなら新規登録、ＰＵＴなら更新。みたいな)

　
・通信には状態を含まない(なにか問題があればHTTPステータスコードで返す)

　

他にもあるけど。
この辺でいいのでは。
　

　

　

あくまで設計原則であり、
設計原則を無視した実装もやろうと思えば出来る
　

RESTを守らないで、やりとりする結果にステータスとか状態に関する情報が入ってれば、疎結合じゃなくなっちゃうかもしれない。
　
　
けど、別に、それもAPIといえばAPI

　

こんだけ。
別に魔法じゃない。技術でもない。

コーディング規約みたいなもんだ。

　

　

　

そうしなきゃいけないわけでもない。

好きにやろうね。

　

　

　

　

まぁ

好きにやりすぎて

RESTになってなくて頭抱えることは多い。
担当者を詰めたくなります(僕は冷たくなります)

　

　

　

　

皆さん難しく考え過ぎです。

　

　
　

僕も難しく考えてました。
ごめんなさい。

　

　

　

　
　

余談

Lambdaって
・REST API
・HTTP API
って種類があると思うんですけど。

こいつら、どっちもやり取りする通信方式はHTTPで設計原則はRESTなんですよね。

REST APIだからHTTP通信じゃないなんてことはないし、
HTTP APIだから設計原則がRESTじゃないなんてことはない。
　

HTTP APIは
・REST APIより安くて
・REST APIより基本的に使える機能が少なくて
・けど一部認証周りでREST APIでは使えない機能が使える
っていう感じの特徴があるだけのREST API

　
というか、
さっきも書いたけど

RESTってただのやり取りのルールだから。
普通にREST守らないAPIも作れる。

誤解を生みやすい。

　
　
　
　

クラウドネイティブな世界は楽しいかと思ってたけど、
今のところ生きにくさの方が強い。

知らなきゃいけないことと、教えなきゃいけないことが多すぎる。

　
　
　
　

人材揃うまであと何年？

共通認識が広まるまであと何年？

教えたら教えたで転職されたんだが？

🥴