アプリやウェブサイトを使ってて、画面がくるくる回って情報が表示されるたびに、実は目に見えない場所で何かと何かが連絡し合ってるって知ってた？そのときに情報を送ってもらう「相手の住所」みたいなものが「エンドポイント」なんだよ。難しく聞こえるけど、ぜんぜん難しくない。この記事を読めば、アプリがどうやってデータを取ってくるのかが理解できちゃうよ。
- エンドポイントは、アプリがデータをもらいに行く「目的地」のようなもの。サーバーのどこに聞きに行くかを指定する。
- URLという形で、「どの情報が欲しいか」を表現できるから、アプリは正確に必要なデータだけを取ってこられる。
- 天気、ニュース、ランキングなど、違う種類の情報は違うエンドポイントに聞きに行く。だから無駄がない。
もうちょっと詳しく
エンドポイントのイメージとしては、大きなコンビニの店舗を思い浮かべるといいよ。コンビニには「レジ」「コーヒーコーナー」「ATM」「荷物受け取り」とか、いろいろなコーナーがあるよね。友だちに「コーヒーが欲しい」って聞いたら、友だちはコーヒーコーナーに案内するじゃん。「ATMはどこ？」って聞いたら、ATMコーナーに案内する。それと同じことをアプリとサーバーでやってるんだ。サーバーには膨大なデータが保管されてるけど、アプリは「僕が欲しいのはこのコーナーのこのデータです」って指定するのがエンドポイント。だから、データも早く返ってくるし、余計な情報をダウンロードしなくていいから、スマホの電池も温存できるってわけ。
エンドポイント＝「サーバーのどこに聞きに行くか」を指定する仕組み。これがあるから、アプリはサーバーの中を迷わずに、欲しい情報を正確にゲットできる。
⚠️ よくある勘違い
→ エンドポイントはサーバーの中にある「特定の場所」。サーバー全体ではなく、その一部なんだ。コンビニ全体じゃなくて、コーヒーコーナーっていう一部分のこと。
→ 「ここに聞きに来たら、このデータをあげますよ」っていう約束の場所。サーバーの中には何個もエンドポイントがある。
[toc]
エンドポイントって何？ホントのところ
スマホアプリとサーバーの会話を想像してみよう
君がスマホで天気アプリを開いて、「東京の今日の気温」を見たいときのことを考えてみて。画面を開くと、くるくるって読み込みが始まって、数秒後に気温が表示されるよね。その裏側では、どんなことが起きてると思う？
実は、こんなやりとりがサーバーと君のスマホの間で起きてるんだ：
スマホ：「ねえ、東京の気温を教えてください」
サーバー：「東京の気温ですね。ちょっと待ってください。25度です」
スマホ：「ありがとうございます。では表示します」
この「ねえ、東京の気温を教えてください」というリクエスト（つまり「お願い」）を、サーバーの中のどこに向かって送るかを指定してるのが、エンドポイントなんだ。
サーバーって、実は「物を保管する大きな倉庫」みたいなもの。その倉庫の中には、天気のデータもあるし、ニュース記事もあるし、ユーザーの個人情報もあるし、いろんなデータがぎゅうぎゅうに詰まってる。でも、アプリはそんな倉庫全体に「ねえ、全部のデータをください」なんて言わないよね。だから、「倉庫の中のどこに行ったら、天気のデータが見つかるのか」っていう目印が必要なんだ。それがエンドポイント。
エンドポイントは、いわば「サーバー倉庫の住所」。より正確には「どのフロアのどのコーナーのどの棚か」を指定するアドレスのようなもの。このアドレスがあるから、アプリはサーバーのデータ倉庫をうろうろしなくて済んで、欲しいデータをピンポイントで取ってこられるわけ。
エンドポイントはURLで表現される
じゃあ、このエンドポイント、実際にはどう見えるのかっていう話。答えはシンプル。URLだ。君が学校のホームページを見るときに、「https://www.example.com/weather」みたいなURLを打ち込むじゃん。その最後の「/weather」の部分がエンドポイントの一つの表し方なんだ。
たとえば、こんな感じ：
「https://api.weather.com/tokyo」
→ weatherサーバーの「tokyoのデータをください」というエンドポイント
「https://api.news.com/technology」
→ newsサーバーの「technologyカテゴリのニュースをください」というエンドポイント
「https://api.youtube.com/videos/trending」
→ YouTubeサーバーの「今トレンドの動画をください」というエンドポイント
なんか複雑に見えるかもしれないけど、ぜんぜん難しくない。このURLを見ると、サーバーは「あ、ここのエンドポイントに聞きに来たか。それなら、このデータをあげましょう」って判断して、必要なデータを返すわけ。
大事なのは「URLの形が決まってる」ってこと。サーバー側の開発者が「このURLで聞きに来たら、このデータを返す」って前もって決めておくんだ。だから、アプリ側は「あ、このURLなら、欲しい情報をくれるな」って信頼して、そこに向かってリクエストを送るってわけ。
APIとエンドポイント、どう違う？
APIはシステム、エンドポイントは場所
ここで、もう一つ大事な言葉が出てくるね。API。「エンドポイント」と「API」は混同されることが多いんだけど、別物なんだ。ちょっと説明しようか。
API（つまり「アプリケーション・プログラミング・インターフェース」）ってのは、アプリとサーバーが「どうやって会話するか」っていうルール全体のことなんだ。いわば「約束事」。
エンドポイントは、その約束事の中で、「データを聞きに行く場所」を指してるわけ。
イメージとしては、こんな感じ：
API = 「銀行の窓口システム全体」
エンドポイント = 「その銀行の中の『振込手続きの窓口』『口座開設の窓口』『両替の窓口』」
銀行に行ったら、いろんな窓口があるじゃん。どの窓口に行くかによって、してくれることが違う。それと同じで、APIの中には、複数のエンドポイントがあるんだ。各エンドポイントは、違う種類のデータや処理を返すための「窓口」の役割を果たしてるってわけ。
だから、「APIがある＝会話の仕組みがある」で、「エンドポイントがある＝その仕組みの中で、具体的にどこに聞きに行くか」ってイメージを持つと、頭がすっきりするよ。
複数のエンドポイントで、いろいろな情報をゲット
たとえば、ツイッターとかインスタみたいなSNSを想像してみて。アプリを開くと、タイムライン（つまり投稿の流れ）が見えるし、アカウント情報も見える。検索もできるし、メッセージだって送受信できる。こんなに沢山の機能があるのに、全部同じサーバーから情報を取ってるんだ。どうやって可能なのか？
それはね、複数のエンドポイントがあるからなんだ。
「https://api.twitter.com/timeline」→ タイムラインデータをください
「https://api.twitter.com/user」→ 自分のアカウント情報をください
「https://api.twitter.com/search」→ 検索結果をください
「https://api.twitter.com/messages」→ メッセージをください
こんな感じで、「同じサーバーだけど、違うエンドポイント」に聞きに行くから、違う情報が返ってくるってわけ。
これって、さっきのコンビニの例と同じだ。一つのコンビニの中に「レジ」「コーヒーコーナー」「ATM」「荷物受け取り」があるのと同じように、一つのサーバーの中に複数のエンドポイントがあるんだ。だから、アプリは柔軟に、必要な情報を、効率的に取ってこられるってわけ。
エンドポイントで何ができるの？
データを「取る」だけじゃない
ここまでの話だと「エンドポイント＝データをもらう場所」って思うかもしれないけど、そうじゃない。エンドポイントを使って、いろんなことができるんだ。
大きく分けるとこんなことができる：
「GET」→ データをもらう。「東京の天気をください」みたいなやつ。
「POST」→ 新しいデータをサーバーに送る。「こういう新しい投稿をしたい」みたいなやつ。
「PUT」→ 既にあるデータを修正する。「この投稿を編集したい」みたいなやつ。
「DELETE」→ データを削除する。「この投稿を消したい」みたいなやつ。
同じエンドポイント（つまり同じURL）に向かって、違う「命令」を送ることで、違う動きをさせることができるんだ。たとえば：
「https://api.twitter.com/tweets」に
GET で聞きに行く → 今のツイートを見る
POST で聞きに行く → 新しくツイートを投稿する
PUT で聞きに行く → 昔のツイートを編集する
DELETE で聞きに行く → ツイートを削除する
同じエンドポイントでも、送る「命令」が違うと、サーバーはそれに応じて違う処理をしてくれるんだ。すごく効率的でしょ？
エンドポイントあるから、セキュリティだって守れる
もう一つ、エンドポイントが便利な理由がある。セキュリティ（つまり「安全性」）を守りやすいってこと。
エンドポイントが決まってれば、サーバーは「このエンドポイントに来た場合は、ここをチェックしよう」って事前に準備できる。たとえば、ユーザーの個人情報を返すエンドポイントなら、「ここに来たリクエストは、ログインしてる人からのリクエストじゃないと答えない」っていう制限をつけることができるんだ。
もし、エンドポイントがなくて、アプリが「全部のデータをください」っていう曖昧なリクエストを送ったら、どうなる？セキュリティチェックが難しくなるし、うっかり個人情報を誰かに見られちゃうかもしれない。だから、エンドポイントで「どの情報にアクセスするか」がはっきり決まってることで、セキュリティもしっかり守れるってわけ。
エンドポイントを使ってみるとこんなメリット
開発者にとってのメリット
アプリを作る人（プログラマー）にとって、エンドポイントがあるとめっちゃ便利なんだ。なぜなら、「サーバーがどうやって動いてるか」を詳しく知らなくても、エンドポイントのURLを知ってれば、欲しい情報が取ってこられるからね。
イメージとしては、こんな感じ。君がスマホのカメラ機能を使うときに「カメラの内部がどうやって動いてるか」を知らなくても、ボタンを押すと写真が撮れるじゃん。それと同じことなんだ。プログラマーは「このエンドポイントに聞きに行けば、このデータが返ってくる」って知ってればいい。サーバーの中身の複雑な仕組みは、サーバー側の人が面倒見てくれる。
こういう「ブラックボックス化」（つまり「中身を知らなくても使える」）ってのは、開発効率をすごく上げるんだ。だからこそ、エンドポイントというシンプルな仕組みが、ウェブの世界では当たり前になってるってわけ。
ユーザーにとってのメリット
アプリを使う君たちにとっても、エンドポイントのおかげでメリットがあるんだ。
まず、アプリの動きが速い。エンドポイントのおかげで、アプリはサーバーに「余計なデータ」をダウンロードしなくて済むから、読み込みが速いんだ。すごく高速な回線じゃなくても、サクサク動く。
次に、データ通信量が少ないから、スマホの容量を節約できる。電話会社からデータ無制限じゃない場合もあるけど、エンドポイントがあるから、無駄な通信を減らせるんだ。
さらに、複数のアプリが「同じサーバーのエンドポイント」を使ってるから、同じ最新情報をみんなが見られるんだ。たとえば、複数の天気アプリがあっても、みんな同じ天気を見てるのは、同じエンドポイントからデータを取ってるからなんだよ。
つまり、エンドポイントは、開発者にも、ユーザーにも、みんなに優しい仕組みなってるってわけ。だからこそ、現代のウェブやアプリの世界では、エンドポイントは不可欠な存在なんだ。
