今回は、REST APIについて解説をまとめていきます。
どもども！こんにちは。レンジのある生活が続いていますが、今までゆでていたのがマイクロウェーブで文明が進んで素晴らしいです。冬が突然襲ってきて、冬眠しそうになっています。冬だと朝は布団が放してくれなくて、夜はなかなか寝付けなくてつらいですな。龍ちゃんです( *´艸｀)。
最初のワンセクションは日記となっていますね。ほぼ社内ツイッターですｗ
前回は、「やさしいAPI解説」と題しまして「APIとは何ぞや？」といった話をしました。そこから話を発展させまして、設計思想であるREST APIについて話をしていきます。設計思想とは具体的に「request・response」の書き方やデータの流れを決めような！という話です。これで前回の知識から一歩だけ進んで、APIについて知れるという流れです。一歩一歩ですよ！では具体的にどういったルールがあるのかについて話していきます。
REST API
「REST API」ですが、「REpresentational State Transfer」の頭文字をとって構成されています。翻訳してくれるサービスにぶち込むと「表現状態遷移」となります。まったく意味が分からないですね。ちょっとカスタマイズとREST APIの機能から意訳すると、「具体的に状態を定義した情報交換手法」となります。まぁ設計手法という言葉にまとまってしまうのですけどね。さてREST APIは4つのルールがあります。以下の図がその言葉ですね。
さて、言葉が固いので難しいですよね。各ルールの説明は簡単にしていきますね。「統一インターフェース・アドレス可能性」については以下の図を用いて説明しますね。
統一インターフェースは、「responseはJSON」・「requestにはHTTPメソッドを使う」といった規格のお話です。アドレス可能性は、アクセスするURLを読んだら何にアクセスするかわかるといった意味ですね。接続性は、responseのJSONにリンクを含んでおいて中身を見たら、どこにアクセスした結果かわかるようにする。ステートレス性は、一度のアクセスで一つの処理が終了する。
さて、4つの項目の説明が終了しました。とても簡単に説明したので、もう少し丁寧に紹介してくれているサイトがあるので紹介だけしておきます。
僕が知りたい部分だとresponseの具体的な書き方なのですが、そこはまた調べて書きますね。
終わりに
ほいほい！お疲れ様です。今回はAPI解説シリーズの第3弾でしたね。正直解説する順番がめちゃくちゃだったので、この順番で読めばAPIの導入が進む！といった順番にするためにはもう少し手順が必要になります。気長に書き進めていきますね。今回の図は、結構な力作になりますね。次は、実際に作るための仕様書の話をしていきます。その前にUXデザインについての話をする必要があるかもしれませんが、そこはいい具合に調整していきます。
僕は今からミーティングが始まるので仕事してきます。
ではでは～
