実務ではMVCフレームワークを使ったアプリがメインですが、
先日Udemyの教材を見ながらGo言語でREST APIの構築を経験しました。
せっかく学習したのでブログにまとめてみたいと思います。
まずREST APIの説明の前にAPIについてご紹介します！
APIとは？？
APIとはソフトウェアの機能を共有することです。
実際にAPIを使用する流れを見てみましょう。
例えば、あるサービスがユーザー情報を提供するAPIを公開していたとします。
1. リクエストを送信
APIに対してGETメソッドを使ってリクエストを送信します。
GET /api/get-users/99
2. APIがプログラムを実行
APIが受け取ったリクエストに基づいてid = 99のユーザー情報をデータベースから取得し、jsonデータに変換します。
3. レスポンスデータを送信
{
"id": "99",
"name": "山田太郎",
"email": "taro.yamada@example.com",
"profile_image": "https://example.com/images/taro.jpg"
}
APIが実行したプログラムからこのようなjsonデータが返されます。
このように１～３の
- データの送信方法
- 処理するプログラム
- レスポンスデータ
これらをまとめてAPIといいます！
REST APIとは？？
REST APIとはAPIを設計するアーキテクチャの１つです。
以下に特徴をご紹介します。
1.リソース指向
REST API はリソースを基に設計します。
そしてリソースごとにURLを割り当てて設計していきます。
リソースとは？
REST APIのリソースとはデータや機能を表現する抽象的なもの。
例）ユーザー（users）記事(articles)、商品（products）
リソースの例
| リソース | 説明 | エンドポイント |
|---|---|---|
| ユーザー | ユーザー情報 | /user |
| 記事 | 投稿される記事 | /article |
URI、URL、エンドポイントってなんや？？
REST APIを進めるなかで、
馴染みのあるURLとは別にURI、エンドポイントという言葉が出てきて混乱します…
用語の整理をしてみました！
| 用語 | 定義 | 例 |
|---|---|---|
| URI | ほぼURLと認識してよい。URLやURN(リソースを識別する番号)を含む広い概念。 | https://api.example.com/users/123 |
| URL | URIの一部で、「リソースの場所」を示すもの。プロトコル、ドメイン、パス、クエリなどを含む具体的なアドレス。 | https://api.example.com/users/123 |
| エンドポイント | API設計において、リソースや機能にアクセスするための接続点。通常はURLのパス部分を指す。 | /users/{id} |
2.HTTPメソッド使い分け
REST APIは、URLに対して、
HTTPメソッドを使い分けてデータを操作します。
例えば、RESTではないAPIの場合は、Userというリソースに対して、
それぞれURLを使い分けて操作します。
| 操作 | エンドポイント |
|---|---|
| 表示 | /user/get/99 |
| 作成 | /user/create/99 |
| 更新 | /user/update99 |
| 削除 | /user/delete/99 |
一方でRESTであるAPIはエンドポイントである/users/{id}に対して4つのHTTPメソッドを使い分けてリソースの操作を行います。
| HTTPメソッド | 処理 |
|---|---|
| GET | リソースの取得 |
| POST | 新しいリソースの作成 |
| PUT | 既存リソースの更新 |
| DELETE | リソースの削除 |
3.ステートレスである！
ステートレス・ステートフルとは？
ステート（状態）レス・フルの違いは、サーバーにログインユーザーの情報を保持しているかどうかの違いになります。
ステートレス
サーバーはログインユーザーの情報を持たず、
各リクエストにログインユーザー情報を乗せて送信されます。
サーバーに状態を保持していないため、
処理がシンプルとなり高速なレスポンスが期待できます。
またサーバーに依存しない設計になっているためスケーラビリティ（負荷分散）が高いです。
デメリット
- クライアント側で状態を管理する必要があるため、実装が複雑になることがある。
- 各リクエストに必要情報を送信する必要があるため冗長性が増す。
ステートフル
ログインしたユーザーの情報がサーバーに格納されます。
例えばショッピングサイトのカートに入っている、
商品の情報はサーバーのセッションに保持されます。
ユーザーはセッションが有効な時間内であれば、
カートに商品が入った状態から買い物を続けることが出来ます。
デメリット
上記のように連続的なユーザー体験を提供できますが、
サーバーに依存することになり障害がユーザーに影響を与えることがあります。
まとめ🖊️
ご覧いただきありがとうございました！
何か気になる点や、おかしな点ありましたらお気軽にコメントください！