Zenn
🍃

Springで作るRESTfulなサービス＜公式チュートリアルに挑戦：前提知識編＞

2022/03/07に公開
Java
Spring Boot
rest
soap
tech

タイトルの通り、RESTfulなサービスをSpringで作る。主に参考にしていくのは、Spring本家が公開している以下のチュートリアル。

https://spring.io/guides/tutorials/rest/

でも今回は、その準備段階として、(1)目的＆(2)REST(ful)とは何かについてまとめていく。主な情報源は、REST APIのチュートリアルより：

https://restfulapi.net/

目的

1.SpringBootのアプリを作って経験値を上げる

先日SpringBootを使って超簡単なアプリを作ってみた。が、自分でもなぜ動いているのか微妙に分かっていない部分も含んだ、怖い代物を作ってしまった。
とはいえ、仕組みの大枠は理解しているとは思う（コントローラーや、サービスレイヤーの役割、DIとは何か等）。でも当初は、「機能はシンプルでも、最新技術を取り入れたアプリを作る」とあんなに意気込んでいたのに。RESTfulなアプリが良さそうだから、そうしようと一人活気に満ちていた私はどこへやら。できたのは、機能もシンプル、RESTfulではない、なんだか中途半端なものだと自負している。

https://github.com/alisazoo/SimpleTokyoDomeCalculator

https://simple-tokyodome-calc.herokuapp.com/place_list

もう少し、この適切な技術を取り入れたアプリを作れるようになりたい。

2.RESTfulなWebアプリは何かを理解する

直前にあったように、「適切な技術」とやらを取り入れるのであれば、まずはいろんな技術の良し悪しを知らなければいけない。RESTfulという言葉に関しても、例外ではない。
なんせ今の私は、WebサービスならRESTfulイコール、新しい！素晴らしい！らしい！！！という、お気楽な思考回路でいる。そもそも、私の作ったアプリはRESTfulにすべきなのか、その辺りも正直理解が足りていない。その辺りを適当に考えられるようになるためにも、RESTfulなWebアプリとは何かについて理解を深めていきたい。

ので、今回は、その第一歩として、RESTfulとはなんぞやというのを、まとめていこうと思う。

知識の整理

RESTとRESTful: RESTfulを考える前に

まずRESTfulとは何かについて考える前に、よく聞くRESTとの違いについてもさらっとおさらい。Devmountainのページによると、APIという文脈で語る上では、RESTもRESTfulも違いはほぼない。厳密には[1]、

  • RESTはAPIの働き方に関する約束事[2]をまとめたもの（アーキテクチャとも言う）
  • RESTfulなAPIは、RESTのお約束事を忠実に守ったAPI

Webアプリについて話す場合はそこまで違いは気にしなくてもよさそうだ。（一応、構造的・アブストラクト寄りの話の場合はREST、実装に関する話ではRESTfulを使うのが適当なようではあるが...）

RESTの原則

RESTはREpresentational State Transferの略語である。上記ではAPIの働き方についてのアーキテクチャという話だったが、もう少し正確に言うと

  • Distributed hypermedia system[3]に関するアーキテクチャのスタイル

らしい。2000年、ネットワーク上で多様な情報をやりとりするためのアーキテクチャとして、Roy Fielding氏の博士論文で初めて提唱された。

RESTには、守らなければならない６つのお約束がある。[4]

  1. インターフェースの統一化
  2. クライアント・サーバー
  3. ステートレス
  4. キャッシャブル
  5. レイヤードシステム
  6. コードオンデマンド

1. インターフェースの統一化 ~自由であるために~

これは、システム全体のアーキテクチャをシンプルにして、やり取りが視覚的にわかりやすくしようという話。具体的には、以下の４つのお約束を守りましょう！

  1. クライアントとサーバーのやり取りで使う、リソースは一意に識別される(uniquely identified)
  2. リソースの操作は、representations(例：JSON)[5]を通して行う
  3. リソースのrepresentationは、クライアント側でのパフォーマンスに十分な情報を持つ
  4. クライアント側はアプリケーションの始めのURLだけを持っているべきであり、その他必要なリソースややり取りは、ハイパーリンクを使って動的に行われる。

2. クライアント・サーバー ~というデザインパターン~

これはデザインパターンのひとつであり、クライアントとサーバー。それぞれを別個の関心(separation of concerns)に集中させ、過度な干渉を防ぐことで、スケーラビリティの向上や、サーバー側のシステムをシンプルにすることができる。

例えば

  • クライアントの関心：ユーザーインターフェース
  • サーバー側の関心：データの格納

のように分けることで、インターフェースだけを他のプラットフォームに移行したりということも可能になる。

3. ステートレス ~たまにしか会わないのにデキる印象の人とのやり取りってこんな感じ~

クライアントからのリクエストは、サーバー側が必要なすべての情報（すべてのセッションステートなど）を含んでいる必要がある。サーバー側は、以前のやり取りをサーバ側に保存して、参照するなんてことはしない。
とにかく、その場その場でのコミュニケーションが命で、ちゃんと必要なことは都度まとめてね、というスタンス。

4. キャッシャブル ~制約あれど使えるものは使います~

サーバーからのレスポンスは、自身がキャッシャブルかそうでないかをラベル化しておく必要がある。
もしキャッシャブルな場合、クライアント側のアプリケーションは、そのレスポンスの使い回しが可能だ（但し、定められた期間内の同等のリクエストに対してのみ）

5. レイヤードシステム ~うちはうち、よそはよそ~

階層化されたレイヤーに、コンポーネントの動作を格納することで、それぞれのコンポーネントの不要な干渉を防ぐ。

6. コードオンデマンド（オプショナル） ~使えそうなものは使って楽をしよう~

外付けコードの使用が可能。クライアント側のコードをシンプルにできる。
具体的には、必要に応じて、クライアント側は、機能を拡張したい場合、アプレットやスクリプトのコードをダウンロードしたり実行することもできる。このメリットとして、事前に実装すべき部分を外から拝借できるようになるため、クライアント側のシステムをシンプルにすることができる。サーバーからもクライアントだけが実装すべき部分をコードという形で転送することで、拡張が可能となる。

別の角度から見るREST -SOAPとの比較

API戦争：　REST　vs． SOAP

またRESTはSOAPと比較されることが多いようだ[6]。両方とも、APIに関する定義方法に関する取り決めではあるが、

  • RESTはアーキテクチャ=原理原則
  • SOAPはプロトコル=規則

よってRESTの場合は、一応守って欲しいことは決まっているが、どこまで守るかは開発者次第。軽いので、IoTやモバイルサービスにも適している。またGoogle MAP APIなどもRESTを準拠している。
一方SOAPは自由度が低く複雑度が高い。規則を守らないとAPIとして機能しない。また、ロード時間も増えてしまう。ただし、その分、セキュリティー、一貫性、耐久性などの観点からはSOAPに歩が上がり、エンタープライズの使用にも耐えうる。

ポストカードなREST vs. 封書なSOAP


Originally from: SOAP vs REST 101: Understand The Differences
これまたよくある比喩。RESTは手軽な感じで、見たらすぐ分かる、ポストカード（最低限、スタンプを貼って、住所を書けばよい）。
一方SOAPは封をしてあるから、封をあける方法を知らなければ、ひと目で何が送られてきたかは分からない。また、送る方も封をしないと送る意味をなさない。ただ、この手続を経る分、情報が外に漏れる必要もなければ、雨風にさらされて肝心の手紙のインクが消えてしまう可能性も、RESTよりは少なくなる。

まとめと今後の展開に関して

RESTってなんだっけ？

  • RESTはAPIの原理原則を定めたアーキテクチャ。RESTの原則を適用したAPIはRESTfulと呼ばれることも
  • RESTは軽量で、サーバーとクライアント側で独立した機能を持ち、情報の共有などはしない。サーバーとクライアントはデキる大人の関係のようだ（個人の感想）。よって、レスポンスする際、クライアントは必ず必要な情報全てを網羅し、サーバーに伝えられなければいけない。
  • その際の情報はJSONなどをrepresentationとして行われる。
  • 自由が多いRESTだからこそ、インターフェースは統一されている
  • コードも機能ごとにのレイヤーを意識し、階層化したコードが好まれる

今後

最終的な目標は、以前作った東京ドーム計算機とやらをRESTfulな感じにして、Google MAP APIも使って地図から場所を選べるようにする。
が、その前段階として、冒頭のSpring Bootのチュートリアルを粛々と進めてみよう。と思う。

個人のつぶやき

こういうシステムとかプログラミングに関して、英語メインで学んだり調べたりしているので、カタカナたくさんの文章に苦手意識があります。いかにコンピューターサイエンス関連の日本語を知らないのだと痛感しました。これも練習だと思って頑張ります。

脚注

  1. What Is the Difference Between REST and RESTful APIs? by Devmountain ↩︎

  2. 原語ではprinciples、constraintsあたりがよく使われている。 ↩︎

  3. 訳語が不明なので、一旦原語のままでお届けします。分散型ハイパーメディアシステムとかになりそう。hypermedia（hypertextを拡張し、テキスト情報でなくあらゆるメディアを扱えるようにしたもの）をネットワーク上で配るために必要なシステムという理解で、よさそう。 ↩︎

  4. What is REST by REST API Tutorial ↩︎

  5. representationもまた、訳しにくい言葉だけど、具体的にはJSONやXMLなどを指すと考えて良さそうだ。What is "representation", "state" and "transfer" in Representational State Transfer (REST)? ↩︎

  6. REST とSOAP：個人的にはこのページ、REST関連の用語について、日本語でどう書くかの勉強になりました。 ↩︎

Discussion