回答編集履歴
1
全体的に回答として成り立つように加筆
test
CHANGED
@@ -1,8 +1,8 @@
|
|
1
|
-
WebサーバやHTTP通信関係の理解
|
1
|
+
WebサーバやHTTP通信関係の理解がかなり不足しているように見受けられます。
|
2
|
-
|
3
|
-
|
4
|
-
|
2
|
+
|
3
|
+
|
4
|
+
|
5
|
-
何となく理解は出来ているの
|
5
|
+
何となく理解は出来ているのだと思いますが、
|
6
6
|
|
7
7
|
ここまで酷い文章だとは…と絶句しましたので、
|
8
8
|
|
@@ -16,6 +16,34 @@
|
|
16
16
|
|
17
17
|
|
18
18
|
|
19
|
+
> 最後に拡張子がついていないようなurlのことです。
|
20
|
+
|
21
|
+
|
22
|
+
|
23
|
+
Webサーバってのはそもそも返す情報が決まっていません。
|
24
|
+
|
25
|
+
HTML、CSS、JS、画像、CSV、JSON、XML……どれもファイルを開けば文字列なんで文字列にしてなんでも送受信出来ます。
|
26
|
+
|
27
|
+
それをして良いのがWebサーバで、基本的にはHTTPレスポンスのヘッダーにあるContent-Typeに書いておくから、ブラウザはそれ見て判断しろと言っています。
|
28
|
+
|
29
|
+
|
30
|
+
|
31
|
+
Apacheなどの静的ファイルを配信するのに特化したWebサーバアプリは、
|
32
|
+
|
33
|
+
URLとマシン内の特定のディレクトリを一致して、ファイルの拡張子等を確認しながら
|
34
|
+
|
35
|
+
Content-Typeの部分を制御しています。
|
36
|
+
|
37
|
+
|
38
|
+
|
39
|
+
という訳で、拡張子があるかないかは別に関係ないし、Webサーバの要件でもありません。
|
40
|
+
|
41
|
+
単にApacheというアプリがそういう作りにしてるし、静的ファイルなら拡張子も用意した方が分かりやすいしファイル名被りも起こらなくて良いでしょ?くらいでしかありません。
|
42
|
+
|
43
|
+
しっかりURLが一意になるように気をつけていれば良いだけの話です。
|
44
|
+
|
45
|
+
|
46
|
+
|
19
47
|
> restという設計モデルを用いた技術らしいのですが、
|
20
48
|
|
21
49
|
|
@@ -109,3 +137,83 @@
|
|
109
137
|
何を言ってるのかわからんと思いますが、HTTPの仕様を理解して、
|
110
138
|
|
111
139
|
その後にRESTfulの思想を理解してください。
|
140
|
+
|
141
|
+
|
142
|
+
|
143
|
+
---
|
144
|
+
|
145
|
+
|
146
|
+
|
147
|
+
以下はHTTP通信周りの勉強が終わったと想定しての説明になります。
|
148
|
+
|
149
|
+
まずHTTPリクエストのヘッダー部にあるURLとメソッドに関して、
|
150
|
+
|
151
|
+
RESTfulはそれに意味を付与することで制御しましょうと言っています。
|
152
|
+
|
153
|
+
|
154
|
+
|
155
|
+
URLは全世界でユニークなりソースを持つものとして表現されます。
|
156
|
+
|
157
|
+
それに対してGET/POST/PUT/DELETEの4種類のメソッドで読み書き削除をしたいというリクエストとして扱いましょうという発想です。
|
158
|
+
|
159
|
+
(最近はPUTじゃなくてPATCHの方が良くね?みたいな話もありますが)
|
160
|
+
|
161
|
+
|
162
|
+
|
163
|
+
- GET: /users/ ユーザ一覧のデータが帰ってくる
|
164
|
+
|
165
|
+
- GET: /users/1 ユーザのID1の詳細情報を取得する
|
166
|
+
|
167
|
+
- POST: /users ユーザ情報に新しい情報を追加
|
168
|
+
|
169
|
+
- PUT: /users/1 ユーザのID1の情報を更新する
|
170
|
+
|
171
|
+
- DELETE: /users/1 ユーザのID1の情報を削除する
|
172
|
+
|
173
|
+
|
174
|
+
|
175
|
+
もちろん、悪意の第三者に貴重なデータを盗まれたり、削除されないよう、
|
176
|
+
|
177
|
+
ログインシステム等を別途構築するなどして、公開する情報、読み書き出来る情報を制御しましょう。
|
178
|
+
|
179
|
+
|
180
|
+
|
181
|
+
ログインユーザがAさんの場合は/usersにアクセスしてもAさんのIDしか教えない、
|
182
|
+
|
183
|
+
ログインユーザがBさんの場合は/usersにアクセスするとAさんとBさんのIDが帰ってくる
|
184
|
+
|
185
|
+
こんな感じ
|
186
|
+
|
187
|
+
|
188
|
+
|
189
|
+
---
|
190
|
+
|
191
|
+
|
192
|
+
|
193
|
+
おまけ: restとRESTfulに関して
|
194
|
+
|
195
|
+
|
196
|
+
|
197
|
+
RESTfulなのにrest、restってなんだよ問題があります。
|
198
|
+
|
199
|
+
これは調べても中々出てこないと思うので先に共有します。
|
200
|
+
|
201
|
+
|
202
|
+
|
203
|
+
一般的にrestと呼ばれるのは、
|
204
|
+
|
205
|
+
RESTful思想にしたがって作られた、JSONを返すWebサーバを指します。
|
206
|
+
|
207
|
+
現場では表記揺れとして、WebAPI、API、RestAPI等と呼ぶ事もあります。
|
208
|
+
|
209
|
+
|
210
|
+
|
211
|
+
JSONで返すのは単純にJavaScriptがAjaxを使って読み書きする時に都合が良いだけの話です。
|
212
|
+
|
213
|
+
昔は超重いXMLファイルとかでやってて、エンジニア達は「俺らちょっとしたデータが欲しいだけなのに、なんでこんな苦行みたいなコード書いてようやっとデータを取り出してるんだ?アホじゃねーか」みたいな事を愚痴っていましたね。
|
214
|
+
|
215
|
+
|
216
|
+
|
217
|
+
ただしJSONは好き勝手記述出来るファイルフォーマットなので、
|
218
|
+
|
219
|
+
フロントエンド側、バックエンド側のデータ様式のやり取りは確実に行うようにしてください。
|