Skip to content

「フォーム」と「HTTPリクエストメソッド」の章を削除し、Fetch APIによる送信を中心とした構成に変更する #856

@chvmvd

Description

@chvmvd

変更に至った背景

最近の開発では、標準のフォーム送信を使用することは少なくなってきており、Fetch APIによる送信が使用されることが多くなってきています。また、実際にこれらを教えている中で、初心者にとっては、標準のフォーム送信よりもFetch APIによる送信の方が理解しやすいように思われます。これらの理由から、2025年現在時点では、標準のフォーム送信ではなく、Fetch APIによる送信を中心とした構成にした方が良いのではないかという意見が主要メンバーの中で支配的になってきているため、「フォーム」と「HTTPリクエストメソッド」の章を削除し、Fetch APIによる送信を中心とした構成に変更することになりました。

新しいFetch APIの章の構成

新しいFetch APIの章は、従来、「フォーム」と「HTTPリクエストメソッド」の章があった、「Expressによるサーバー構築」と「データベース」の章の間に置くことが良いと考えられます。

新しいFetch APIの章の構成については次のようになります。

新しいFetch APIの章の構成は、従来のFetch APIの章と同様のものを想定しています。
Fetch APIの章は、大きく、Fetch APIを使ったGETリクエスト、Fetch APIを使ったPOSTリクエストに分けられます。また、リクエストがクエリパラメータかJSONか、レスポンスかテキストかJSONかでも分けることができます。そのため、次のように細分化できます。

  • GETリクエストで、レスポンスがテキスト
  • GETリクエストで、レスポンスがJSON
  • POSTリクエストで、リクエストがクエリパラメータで、レスポンスがテキスト
  • POSTリクエストで、リクエストがJSONで、レスポンスがテキスト
  • POSTリクエストで、リクエストがJSONで、レスポンスもJSON

ここで、POSTリクエストで、リクエストがクエリパラメータのものについては、説明しないことにします。これに関しては、次のような理由となります。実際の開発において、リクエストボディではなく、クエリパラメータに情報を保持するべき場面も多々見られるため、クエリパラメータは依然として重要であり、知っておくべき知識ではあります。一方、教材では以降使う場面はないため、教材で少し説明するだけでは、学習者が混乱することが考えられます。これらのバランスを鑑みて、リクエストがクエリパラメータのものについては、説明しないこととしました。

また、POSTリクエストで、レスポンスがテキストであるものは、取り立てて説明しないこととします。これは、レスポンスがテキストのものは、実際に使われる機会はかなり少ないため扱う必要性が薄く、すでにGETリクエストでレスポンスがテキストのものは説明しているため、改めて説明する必要がないと考えられるからです。

以上を踏まえて、次のような構成にしました。

  • GETリクエストで、レスポンスがテキスト
  • GETリクエストで、レスポンスがJSON
  • POSTリクエストで、リクエストがJSONで、レスポンスもJSON

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions