前回の続き——要求の「種類」を決める言葉
D-03で見たとおり、HTTPリクエストの一行目には、いちばん先頭にメソッドが置かれていました。前回のD-04では、その要求に対する返事であるレスポンスの読み方を確認しました。今回は視点を要求側へ戻し、一行目の先頭にあったメソッドそのものに注目します。メソッドは、その要求で「何をしたいか」を相手に伝える種類の指定です。ここを理解すると、同じ宛先でも動きが違う理由がつながります。
このスライドのポイント
- D-03で、リクエストの一行目にメソッドがあると見た
- D-04では、その応答であるレスポンスの読み方を扱った
- 今回は、一行目の先頭にある「メソッド」そのものの種類と使い分けに入る
5つのメソッドの意図
メソッドとは、その要求で「何をしたいか」を表す種類のことです。代表的なものは五つあります。GETは取得で、データを変更しません。POSTは新規作成や処理の依頼に使います。PUTは対象を丸ごと置き換え、PATCHは一部だけを更新します。そしてDELETEは削除です。まずはこの五つの意図を、言葉として押さえてください。取得だけは何も変えない、残りの四つは何かを変える、という感覚を持っておくと後がわかりやすくなります。
このスライドのポイント
- メソッド＝その要求で「何をしたいか」の種類
- GET＝取得（データを変更しない）
- POST＝新規作成・処理の依頼
- PUT＝丸ごと置き換え／PATCH＝一部だけ更新
- DELETE＝削除
なぜメソッドを知る必要があるか
メソッドを知らないと、「同じURLなのに動きが違う」という現象が最後まで謎のままになります。さらに困るのは、危うい設計に気づけなくなることです。たとえばGETは本来データを変更しないという約束ですが、これを破ってデータを書き換える処理にGETを使う設計があり得ます。メソッドの意図を知らなければ、AIが作ったコードがそうした約束に反していても見抜けません。意図を押さえることは、生成物の安全性を確認する土台になります。
このスライドのポイント
- 「同じURLなのに動きが違う」が謎のままになる
- データを変更する処理にGETを使うなど、約束に反した危うい設計に気づけない
- 意図の取り違えは、AIの生成物を見ても見抜けなくなる
宛先は名詞、メソッドは動詞
全体像を一言で言うと、URLは宛先という名詞、メソッドは動作という動詞です。たとえば同じ宛先である「タスク7番」に対して、動詞であるメソッドを変えると、見る・書き換える・消すというように処理が変わります。ここに安全の軸を重ねておきましょう。GETは何度繰り返しても変更しないという約束なので安全側です。一方でDELETEは、A-09で見たリスクレベルの高い側にあたります。意図の違いは、そのまま危険度の違いでもあります。
このスライドのポイント
- URL＝宛先（名詞）、メソッド＝動作（動詞）という対応
- 同じ宛先 /api/tasks/7 でも、動詞を変えると処理が変わる
- 安全の軸: GETは繰り返しても安全（変更しない約束）／DELETEはA-09で見た高リスク側
同じ宛先を、見る・書き換える・消す
具体例で流れをつかみましょう。タスク管理アプリを考えます。タスクの7番を「見る」「書き換える」「消す」という三つの操作は、実はすべて同じ宛先に向かいます。違うのはメソッドだけです。見るならGET、書き換えるならPUTやPATCH、消すならDELETEを、同じ「タスク7番」という場所に送り分けます。宛先はどの場所かを示し、メソッドはその場所で何をするかを示す。この二つの組み合わせで、一つひとつの要求の意味が決まっているのです。
このスライドのポイント
- タスク管理アプリで、タスク7番を「見る・書き換える・消す」は全部同じ宛先
- 違うのはメソッドだけ
- 宛先が場所、メソッドがその場所で何をするか
技術サンプル: メソッドと処理の対応表
実際の対応表を読みましょう。GETでタスク7番を取得しても、データは変わりません。PUTは丸ごと置き換え、PATCHは一部だけ更新、DELETEは削除です。四つとも宛先は同じですが、処理はメソッドで分かれています。一方でPOSTだけは宛先が「タスク一覧」の側で、これはまだ番号のない新しいタスクを作るからです。注意点として、DELETEはA-09の高リスク変更にあたります。取り消せない削除には、実行前の確認を必ず置いてください。
このスライドのポイント
- 種別: http
- 目的: 同じ宛先でもメソッドで処理が変わることを一覧で確認する
- サンプル本体:
PUTとPATCHの違い
混同しやすいのがPUTとPATCHです。PUTは対象を丸ごと置き換え、PATCHは一部だけを更新します。ここには落とし穴があります。丸ごと置き換えるPUTに、一部の項目だけを送ってしまうと、送らなかった残りの項目が空になって消える、という設計があり得ます。名前だけ直したいのに、他の情報まで失う事故につながります。もう一組、GETとPOSTも押さえましょう。GETは何も変えない取得、POSTは変更を伴う依頼です。取得か変更かを、まず見分けてください。
このスライドのポイント
- PUT＝丸ごと置き換え vs PATCH＝一部だけ更新
- PUTで一部だけ送ると、残りが消える設計があり得る
- 補助: GET vs POST（取得 vs 変更を伴う依頼）
バイブコーディングでの確認点
AIにAPIを作らせたら、メソッドの使い方を必ず確認しましょう。まず「データを変更する処理に、GETを使っていませんか」と聞きます。GETは変更しない約束なので、ここが破られていると危険信号です。次に「DELETEの前に確認画面はありますか」と聞きます。取り消せない削除には、一段止まる仕組みが要ります。そして、変更を伴うPOST・PUT・PATCH・DELETEは、A-04で見た差分確認の対象です。何をどう変えたのかを、生成のたびに確かめてください。
このスライドのポイント
- AIが作ったAPIに「データを変更する処理にGETを使っていませんか」と聞く
- 「DELETEの前に確認画面はありますか」を聞く
- 変更系メソッド（POST・PUT・PATCH・DELETE）はA-04の差分確認の対象
まとめと次回
一問一答です。一部だけ更新したいときのメソッドは何でしょうか。……答えはPATCHです。丸ごと置き換えるPUTと混同しないでください。三十秒でまとめます。URLは宛先という名詞、メソッドは動作という動詞でした。同じ宛先でもメソッドで処理が変わり、GETは取得、変更を伴うPOST・PUT・PATCH・DELETEは確認が要ります。次回は、返ってくる三桁の数字であるステータスコードを、分類して読めるようにします。関連資料は「API連携 超入門」「API連携ワード100」「AIアプリ公開前チェックリスト100」です。
このスライドのポイント
- 一問一答:「一部だけ更新したいときのメソッドは？」→ PATCH
- 30秒まとめ: URLは宛先、メソッドは動作。5つの意図を区別し、変更系は確認する
- 次回: 返事の3桁の数字＝ステータスコードを分類して読む
- 関連資料: 「API連携 超入門」「API連携ワード100」「AIアプリ公開前チェックリスト100」
