O’REILLY Learning「Microservice APIs」1〜5

2023年2月14日

https://learning.oreilly.com/library/view/microservice-apis/9781617298417/

1 What are microservice APIs?

This chapter covers
・What microservices are and how they compare with monolithic applications
・What web APIs are and how they help us drive integrations between microservices
・The most important challenges of developing and operating microservices

最も重要な概念である「マイクロサービス」と「API」を定義しています。
マイクロサービスは、システムのコンポーネントが独立して展開可能なサービスとして設計されているアーキテクチャスタイルであり、APIはそれらのサービスと対話するためのインターフェイスです。

Sam Newmanは、最小限の定義を提供しています。
「マイクロサービスとは、互いに連携して動作する小規模で自律的なサービスである」

James LewisとMartin Fowlerが書いた論文
「1つのアプリケーションを小さなサービスの集合体として開発するアプローチ」と定義しており、それぞれが独自のプロセスで動作し、軽量なメカニズム（多くの場合HTTPリソースAPI）で通信します。
https://martinfowler.com/articles/microservices.html

モノリスとは、アプリケーション全体を単一のビルドとしてデプロイするアーキテクチャパターンである。

マイクロサービスがもたらす最も重要な課題
・効果的なサービスの分解
・マイクロサービス統合テスト
・サービス不能時の対応
・分散トランザクションのトレース
・運用の複雑さとインフラのオーバーヘッドの増加

Schema Definition Language (SDL)

2 A basic API implementation

This chapter covers
・Reading and understanding the requirements of an API specification
・Structuring our application into a data layer, an application layer, and an interface layer
・Implementing API endpoints using FastAPI
・Implementing data validation models (schemas) using pydantic
・Testing the API using a Swagger UI

OpenAPIを使ったAPIの文書化

FastAPI(https://github.com/tiangolo/fastapi)
Starlette(https://github.com/encode/starlette)
Uvicorn(https://github.com/encode/uvicorn)

3 Designing microservices

This chapter covers
・Principles of microservices design
・Service decomposition by business capability
・Service decomposition by subdomain

3つの設計原則
・Database-per-service principle
　特定のサービスが所有するデータに、他のサービスが直接アクセスできないようにすること。
　各マイクロサービスが完全に異なるデータベースに接続されるべきであるという意味ではない。
・Loose coupling principle
　関心事を明確に分離してサービスを設計しなければならない。
・Single Responsibility Principle (SRP)
　少ない責任でコンポーネントを設計し、理想的には1つの責任だけで設計しなければならない。

Decomposition by business capability vs. decomposition by subdomain

4 Principles of REST API design

This chapter covers
・The design principles of REST APIs
・How the Richardson maturity model helps us understand the advantages of REST best design principles
・The concept of resource and the design of endpoints for REST APIs
・Using HTTP verbs and HTTP status codes to create highly expressive REST APIs
・Designing high-quality payloads and URL query parameters for REST APIs

Representational State Transfer (REST)
Roy Fieldingの博士論文「Architectural Styles and the Design of Network-based Software Architectures」（博士論文、University of California, Irvine, 2000, p. 109）で使われた造語

シングルトンエンドポイント
コレクションエンドポイント

HATEOASとは一体何なのか？
2008年に書かれた「REST APIs Must Be Hypertext-Driven」

REST APIs must be hypertext-driven

REST APIはレスポンスに関連リンクを含み、クライアントがそのリンクをたどってAPIを移動できるようにしなければならないと提案
あなた自身のAPIに取り組むとき、HATEOASの原則に従うかどうか決めることができる。

Richardson 成熟度モデル
Level 0～3
Level 0: Web APIs à la RPC
Level 1: Introducing the concept of resource
Level 2: Using HTTP methods and status codes
Level 3: API discoverability→HATEOAS の原則を適用

GET、POST、PUT、 PATCH、 DELETE
CRUD：作成（POST）、読み取り（GET）、更新（PUTとPATCH）、および削除（DELETE）

Payloads：HTTP リクエストを通じてクライアントとサーバーの間で交換されるデータ

URL クエリパラメータはこれらの目的を達成するためのもので、常にオプションであるべき。

5 Documenting REST APIs with OpenAPI

This chapter covers
・Using JSON Schema to create validation models for JSON documents
・Describing REST APIs with the OpenAPI documentation standard
・Modeling the payloads for API requests and responses
・Creating reusable schemas in OpenAPI specifications