HTTPメソッド・アーキテクチャ - ネットワーク

最終更新日: 2026-07-25

TOP(About this memo)) > 一覧(ネットワーク) > HTTPメソッド・アーキテクチャ

GET/POST/PUT/DELETE

• まとめ
  • GET,POSTの違いをURLに乗せるか乗せないかの違いと考えるのは正確さに欠ける。まずは役割で考えるべき。
  • それとは別に、セキュリティの観点でURLに機密情報は乗せるべきではない。
    • セキュリティ上POSTを使う、という理解は正確ではない。
• いずれのメソッドでもヘッダー情報は自由に変えられる。つまり、ヘッダーにトークンなどをもたせることはできる。
• GETはデータを取得したい場合に使うもの（更新があるべきではない）。?の後ろにつけるパラメーターは、あくまでもデータ取得において使うパラメータ。
  • たとえば、トークンを使ったデータ取得の場合は、GETでヘッダーにトークンを乗せればよい。
• POSTはデータをボディで指定する。
  • 実はPOSTでも?の後ろにパラメータをつけられる（あまりやるべきではないと思われる(IMO)）。
• (参考) http://tooljp.com/windows/chigai/html/Internet/GET-POST-PUT-chigai.html
• よってデータを取得する場合でも、データをクエリストリングに乗せたくない場合はPOSTを使う。
• PUTはクライアントが作成したいリソースのURIが明確である場合に用いる。一方POSTは新しく作成されるリソースのURIがサーバーによって決まる場合に用いる。SQLに例えるならば、PUTはIDを伴うINSERT文だが、POSTはIDを伴わないINSERT文である。
• POSTはべき等ではなく、PUTはべき等とされている。

HTTP前提のアーキテクチャ

RPC

• 外部のプログラムが提供するプロシージャを呼び出す仕組み。
• すべてPOSTで対応可能なシンプルさがあり、複数言語に渡るプログラム間で条件分岐する場合でも直接メソッドでの操作が可能。
• メソッドが直接エンドポイントに作用するので機能追加がしやすい。
• ペイロードが軽量になるためパフォーマンスが出やすい。
• (参考) https://mattylogs.com/blog/9/
• (IMO) サーバー間のプロセス通信には向いていそうだが、WebのフロントとバックのようなI/F構造では、フロントからメソッドとして直接呼び出せることの利点はあまり無いように感じる。
• (IMO) そもそもRPCは、サーバー間のネットワークが分離していることを意識させない（抽象化する）ことが目的の技術という気もする。

gRPC

• (参考) https://www.slideshare.net/disc99_/apirestgrpc
• Googleが公開したRPCのプロトコルで、通信プロトコルがHTTP/2。
  • WebSocketやHTTPのレイヤではなく、「約束事」という意味でのプロトコル(?)。
    • (参考) https://twitter.com/voluntas/status/1629711059992080385?cxt=HHwWgsDTleLk8p0tAAAA
• Protocol Buffersによりサービスのインターフェース定義を行う。
  • 構造化されたデータをシリアライズするための言語非依存なプラットフォーム。
  • IDL(インターフェース定義言語)によって記述。
  • 主要な言語へのソースコード生成が可能。
  • デメリット
    • 現状ブラウザから使えないこと。
    • シリアライズされているため、JSONのように気軽に呼び出し・デバッグができない。
• (IMO) 実際に使うときにデバッグがやりづらそうに感じる。
• (参考) gRPCを実装して解説： https://zenn.dev/hsaki/books/golang-grpc-starting/viewer/intro
• (参考) Golang grpc flutterの例： https://flutterawesome.com/flutter-mobile-app-which-communicates-with-golang-server-over-grpc/amp/

gRPC-Web

• gRPC通信をWebでも使うことができるもの。ブラウザはHTTP/2の低レベルな制御ができないため、ブラウザから直接gRPCサーバーを呼び出すことはできず、gRPC-Web用のプロキシ（Envoyなど）を経由する構成が必要になる。
• プロジェクト自体は既にGA(Generally Available)となっているが、クライアントストリーミングや双方向ストリーミングは執筆時点でも未対応。
• プロキシを立てる構成が前提になる分、実装コストはそれなりに大きい(IMO)。
• 通常のWebシステムでこれを使うメリットは大きくないように思う（大規模なストリームなどの通信が高速化するケースくらい(IMO)）。近年は、ブラウザから追加のプロキシなしで直接呼び出せるConnectが代替として使われることも増えている(IMO)。

REST(REpresentational State Transfer)

• URLがリソースになっていること。名詞であることが原則。
• ステートレスであること。
• HTTPプロトコルによって一貫性かつ互換性のある操作を行える(登録はPOST、取得はGET、削除はDELETEなど)。
• URLを見ることで、URLの機能とそのレスポンス情報を解読しやすく、エンドポイントを見ればどういうデータが行き交ったのかが理解しやすい(IMO)。
• サーバー側とは受け取るリソースのみの認識共有で済むので、フロントとバックがそれぞれの相互依存を気にせず開発に集中できる。

SOAP

• (IMO) 通常はRESTを使えばよいと思う。
• 通信プロトコル（規約）の一つ。
• メッセージの記述にXMLを、データ伝送に主にHTTPを用いる。
• Webサービスの提供や利用に適しているとされる。
• 仕様が複雑なため、敬遠されるようになった。現在はRESTの方がメジャー。
  • JavaScriptなどで書くと、リクエストもレスポンスも長くなるため使いづらい(IMO)。
• SOAPとREST
  • (IMO) SOAPは現在ではあまり使われなくなっている。RESTの捉え方についても議論が分かれることがある。
  • (参考) https://jp.quora.com/Web開発におけるRESTやRESTfulとはなんですか-そうでは無いもの

GraphQL

• (TODO) 別途整理する。

This site is open source. Improve this page.