Coursera Service-Oriented Architecture Week3 REST Service

REST API設計の注意点

  • URIには名詞のみを使う 例えば、大学用のAPIを作るとしたら、/students/や/students/SID/coursesのように、名詞をURIに使う。 (ただしこれは厳密にRESTfulであるとはいえない。よいURIは、リソースを示し、クライアントがそれに容易にアクセスできるようにする)

  • GETメソッドはリソースの状態を変えない GETメソッドは、リソースを参照するためだけに使う。リソースの状態に影響を与える操作は、POST、PUT、DELETEメソッドで行う

  • URIには複数形を使う x student -> o students

  • リソースとリソースの関係を表すためには、サブリソースを使う 例えば、生徒がコースをとっているということを表すために、/students/SID/coursesというようにサブリソースを使用する。

  • 入力/出力フォーマットを指定するためにHTTPヘッダーを使う Content-Typeでリクエストメッセージのフォーマット、Acceptで期待するレスポンスメッセージのフォーマットを指定する。

  • クエリパラメーターでフィルターやオフセットの指定ができるようにする /students?name=hogeのように

  • APIをバージョンづけする 既存のAPIを変えずに、新しいバージョンをリリースできるよう、URIにバージョン番号を含めるとよい

  • 適切なHTTPステータスコードを使用する

マイクロサービス

巨大なチームで作られる一枚岩(同じコードベース)のシステムには、 - メンテナンスしづらい - スケールしづらい - 開発期間が長くなる - パフォーマンスが悪い 等の問題が出てくる。 これに対応するために、Service Oriented Architectureは、巨大なシステムを小さい機能ごとにサービスとして分割し、それぞれのサービスは疎結合カプセル化されているようにすることを提案する。

マイクロサービスは、Service Oriented Architectureのバリエーションの一つである。 マイクロサービスのアーキテクチャスタイルは、マイクロサービスを組み合わせて一つのアプリケーションを作り上げるためのものである。 マイクロサービスは、一つの独立したタスクに対して責務を持つ。例えば、あるアプリケーションの中で、一つのマイクロサービスは検索機能の責務をもち、また一つのマイクロサービスはレコメンド機能の責務を持つなどである。 マイクロサービスはそれぞれ独立して開発される。マイクロサービスはしばしばレイヤードアーキテクチャーのすべての層を実装しない。なぜなら、マイクロサービスは他のマイクロサービスと連携することを意図しており、例えばエンドユーザー向けのプレゼンテーション層を持たない場合があるからである。

マイクロサービス同士のやりとりでは、HTTPがよく使われる。RESTインターフェースは、マイクロサービス同士のステートレスなコミュニケーションによく用いられる。

マイクロサービスには、次のような利点がある。 - マイクロサービスは、そのサービスに適した言語、フレームワークアーキテクチャを使うことができる。そのため、実装したい機能に一番適した組み合わせで開発を行うことができ、開発者も新しいテクノロジーを使うことができる。 - 疎結合なので、スケールやメンテナンスがしやすい。 - 一つのサービスは一つの小さなチームによって独立に開発されるので、素早く開発できる - コードのメンテナンス性が高くなる

しかし、次のような欠点もある。 - それぞれのサービスは分散し、非同期に動作するため、すべてのサービスを管理する中央システムが必要になる - それぞれのサービスが独自にデータベースを持っているため、トランザクション範囲が複数のサービスに及ぶ - 複数のサービスに渡ったテストが難しい - すべてのサービスは、他のサービスが処理に失敗したときのことを考えて実装されなければいけない - サービス同士のコミュニケーションにコストがかかる