HTTP Request

មាតិកា

1. HTTP គ្រាន់តែជាអក្សរ
2. Request Line
3. Method៖ អ្វីដែលអ្នកចង់ធ្វើ
4. Safe និង Idempotent
5. Header៖ ព័ត៌មានបន្ថែម
6. Body
7. ការផ្ញើ Request ជាមួយ curl
8. ការអាន Request នៅក្នុង DevTools
9. សាកល្បងដោយខ្លួនឯង

1. HTTP គ្រាន់តែជាអក្សរ

ការតភ្ជាប់ពីជំពូកទី 4 ត្រូវបានបើកហើយ។ ឥឡូវ browser ផ្ញើ request របស់វា — ហើយនេះគឺជាផ្នែកដែលគួរឲ្យភ្ញាក់ផ្អើល៖ HTTP request មួយគឺគ្រាន់តែជា អក្សរធម្មតា (plain text) ពីរបីបន្ទាត់ប៉ុណ្ណោះ។ នេះគឺជាអ្វីដែល browser របស់អ្នកផ្ញើ នៅពេលអ្នកបើក site GitHub Pages របស់អ្នក៖

GET /my-site/ HTTP/1.1
Host: dara-sok.github.io
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/130.0
Accept: text/html,application/xhtml+xml
Accept-Language: km-KH,km;q=0.9,en;q=0.8
Accept-Encoding: gzip, br
Connection: keep-alive

នោះហើយជាអ្វីៗទាំងអស់។ HTTP — HyperText Transfer Protocol — គឺជាសំណុំច្បាប់ដែលកំណត់ថាបន្ទាត់ទាំងនោះត្រូវមើលទៅដូចម្តេច។ Request នីមួយៗមានរូបរាងដូចគ្នា៖

 1. Request line     GET /my-site/ HTTP/1.1
 2. Headers          Host: …, User-Agent: …, …
 3. A blank line     (marks the end of the headers)
 4. Body (optional)  data being sent, e.g. a form

(HTTP/2 និង HTTP/3 ផ្ញើព័ត៌មានដូចគ្នា ក្នុងទម្រង់ binary បង្រួមជំនួសឲ្យអក្សរ ប៉ុន្តែអត្ថន័យគឺដូចគ្នាទាំងស្រុង។ DevTools និង curl បង្ហាញវាដល់អ្នកជាអក្សរ ទោះបីជាយ៉ាងណាក៏ដោយ។)

2. Request Line

បន្ទាត់ទីមួយមានបីផ្នែក៖

GET  /my-site/  HTTP/1.1
 │       │         └── which version of HTTP
 │       └──────────── which resource: the path (+ query) from the URL
 └──────────────────── the method: what you want to do with it

សម្គាល់អ្វីដែល មិន មាននៅទីនោះ៖ scheme និង host មិននៅក្នុងបន្ទាត់នេះទេ (host មាន header ផ្ទាល់ខ្លួន នៅជាប់នោះ) ហើយ fragment ពីជំពូកទី 2 មិនមាននៅកន្លែងណាសោះ — browser មិនដែលផ្ញើវាទេ។

3. Method៖ អ្វីដែលអ្នកចង់ធ្វើ

Method គឺជាកិរិយាសព្ទមួយ។ Path និយាយថា resource មួយណា ហើយ method និយាយថា ត្រូវធ្វើអ្វី ជាមួយវា។ ទាំងនេះគឺជា method ដែលអ្នកនឹងប្រើ៖

មាន method ពីរបីទៀត — HEAD (ដូច GET ដែរ ប៉ុន្តែផ្ញើតែ header ប៉ុណ្ណោះ) និង OPTIONS (តើខ្ញុំត្រូវបានអនុញ្ញាតឲ្យធ្វើអ្វីខ្លះនៅទីនេះ?) គឺជា method ដែលអ្នកនឹងជួប ដោយ method ទីពីរនៅក្នុងជំពូកទី 10។

នៅពេលអ្នកចុចលើ link ឬវាយ URL មួយ browser តែងតែប្រើ GET។ នៅពេលអ្នក submit form មួយ ជាធម្មតាវាប្រើ POST។ Method ផ្សេងទៀតត្រូវបានប្រើភាគច្រើនដោយ JavaScript និងដោយកម្មវិធីដែលនិយាយជាមួយ API — អ្នកនឹងសរសេរវាដោយខ្លួនឯងនៅក្នុង NestJS Crash Course ដែល controller មួយមាន function ដាច់ដោយឡែកសម្រាប់ @Get(), @Post(), @Patch() និង @Delete() លើ path តែមួយ។

4. Safe និង Idempotent

ពាក្យពីរពិពណ៌នាអំពីអ្វីដែល method មួយសន្យា៖

• Safe៖ វាមិនផ្លាស់ប្តូរអ្វីនៅលើ server ទេ។ GET និង HEAD គឺ safe — ការ load ទំព័រមួយមិនគួរលុប account របស់អ្នកទេ។
• Idempotent៖ ការធ្វើវាពីរដង មានឥទ្ធិពលដូចគ្នានឹងការធ្វើវាម្តង។ GET, PUT និង DELETE គឺ idempotent។ ការលុប comment លេខ 7 ពីរដង នៅតែទុកឲ្យ comment លេខ 7 ត្រូវបានលុបដដែល។

POST មិនមែនទាំងពីរ។ ការ submit form បញ្ជាទិញពីរដង អាចបង្កើតការបញ្ជាទិញពីរ។ នោះហើយជាមូលហេតុដែល browser របស់អ្នកព្រមាន «Confirm form resubmission» នៅពេលអ្នក refresh ទំព័រដែលអ្នកទទួលបានពី POST ហើយហេតុអ្វី payment API ដូចជា ABA PayWay នៅក្នុង tutorial របស់ site នេះ ប្រុងប្រយ័ត្នដើម្បីជៀសវាងការកាត់លុយនរណាម្នាក់ពីរដង។

ច្បាប់សម្រាប់ពេលអ្នកបង្កើតអ្វីមួយ៖ កុំប្រើ GET សម្រាប់អ្វីដែលផ្លាស់ប្តូរទិន្នន័យ។ Browser, search engine និង link preview ទាំងអស់ សេរីក្នុងការផ្ញើ GET request ពេលណាក៏បានតាមចិត្ត ដោយសន្មតថាគ្មានអ្វីនឹងផ្លាស់ប្តូរទេ។

5. Header៖ ព័ត៌មានបន្ថែម

បន្ទាប់ពី request line គឺជា header៖ មួយក្នុងមួយបន្ទាត់ ដែលសរសេរជា Name: value។ ពួកវាផ្ទុកអ្វីៗផ្សេងទៀតទាំងអស់ដែល server ប្រហែលជាត្រូវដឹង។ ឈ្មោះ header មិនប្រកាន់អក្សរធំតូចទេ។ Header ទូទៅ៖

ហេតុអ្វី Host ចាំបាច់? ព្រោះកុំព្យូទ័រ server មួយ — IP address មួយ — ជារឿយៗ host website រាប់ពាន់។ Site GitHub Pages ទាំងអស់ចែករំលែក IP address ដូចគ្នាពីរបី។ Header Host គឺជាវិធីតែមួយគត់ដែល server របស់ GitHub ដឹងថាអ្នកចង់បាន dara-sok.github.io មិនមែន site របស់អ្នកផ្សេងទេ។

q=0.9 នៅក្នុង Accept-Language: km-KH,km;q=0.9,en;q=0.8 គឺជាទម្ងន់នៃចំណូលចិត្តពី 0 ដល់ 1៖ «ភាសាខ្មែរ (កម្ពុជា) មុនគេ បន្ទាប់មកភាសាខ្មែរណាមួយ បន្ទាប់មកភាសាអង់គ្លេស»។ Site ដែលគាំទ្រភាសាច្រើន អាចប្រើវាដើម្បីជ្រើសរើសភាសាមួយសម្រាប់អ្នក។

6. Body

GET request គ្មាន body ទេ — អ្វីៗទាំងអស់ដែលពួកវាត្រូវការគឺនៅក្នុង URL។ POST, PUT និង PATCH ជាធម្មតាមាន។ Header Content-Type និយាយពីរបៀបអានវា។ អ្នកនឹងឃើញពីរប្រភេទញឹកញាប់ជាងគេ។

Form HTML បុរាណមួយ ផ្ញើ field របស់វាដូចជា query string៖

POST /signup HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 38

name=Dara+Sok&email=dara%40example.com

កម្មវិធី ឬ JavaScript ដែលហៅ API ជាធម្មតាផ្ញើ JSON៖

POST /api/orders HTTP/1.1
Host: shop.example.com
Content-Type: application/json
Content-Length: 32

{"productId": 42, "quantity": 2}

Content-Length និយាយថា body មានប៉ុន្មាន byte ដូច្នេះ server ដឹងថាវាបញ្ចប់នៅត្រង់ណា។ សម្គាល់បន្ទាត់ទទេរវាង header និង body — នោះហើយជារបៀបដែល server ដឹងថា header បានចប់ហើយ។

ចាំពីជំពូកទី 4៖ ជាមួយ HTTPS អ្វីៗទាំងអស់នេះ — header និង body — ត្រូវបាន encrypt។ ជាមួយ HTTP ធម្មតា អាសយដ្ឋាន email នោះអាចអានបានដោយអ្នកគ្រប់គ្នាតាមផ្លូវ។

7. ការផ្ញើ Request ជាមួយ curl

curl អនុញ្ញាតឲ្យអ្នកសរសេរ request ដោយដៃ។ Option មួយចំនួនដែលអ្នកនឹងប្រើជានិច្ច៖

curl https://example.com                 # GET, print the body
curl -v https://example.com              # also show request + response headers
curl -I https://example.com              # HEAD: headers only
curl -X POST https://example.com/api     # use a different method
curl -H "Accept-Language: km" https://example.com   # add a header
curl -d "name=Dara" https://example.com/signup      # send a body (implies POST)

ជាមួយ -v បន្ទាត់ដែលចាប់ផ្តើមដោយ > គឺជាអ្វីដែល អ្នកបានផ្ញើ ហើយបន្ទាត់ដែលចាប់ផ្តើមដោយ < គឺជាអ្វីដែល ត្រឡប់មកវិញ៖

> GET /my-site/ HTTP/2
> Host: dara-sok.github.io
> User-Agent: curl/8.7.1
> Accept: */*
>
< HTTP/2 200
< content-type: text/html; charset=utf-8
< …

មើលថា request របស់ curl ខ្លីប៉ុណ្ណា បើធៀបនឹងរបស់ browser។ Accept: */* មានន័យថា «ខ្ញុំយកអ្វីក៏បាន»។ Server មិនត្រូវការ header បន្ថែមទាំងអស់នោះទេ ហើយ browser ផ្ញើវាដើម្បីទទួលបានកំណែល្អបំផុតនៃទំព័រមួយ។

អនុវត្តដោយសុវត្ថិភាព៖ site https://httpbin.org មានសម្រាប់គោលបំណងនេះពិតប្រាកដ។ វាបញ្ជូនត្រឡប់មកវិញនូវអ្វីក៏ដោយដែលអ្នកផ្ញើទៅវា ដូច្នេះអ្នកអាចសាកល្បង method ណាមួយក៏បាន ដោយមិនធ្វើឲ្យអ្វីខូច។ curl https://httpbin.org/get បង្ហាញអ្នកនូវ request ផ្ទាល់ខ្លួនរបស់អ្នក ដូចដែល server បានឃើញ។

8. ការអាន Request នៅក្នុង DevTools

នៅក្នុង browser៖

1. បើក DevTools → Network ហើយ reload ទំព័រ។
2. ចុចលើ request មួយនៅក្នុងបញ្ជី។
3. Tab Headers បង្ហាញ URL, method និង status code នៅខាងលើ (ក្រោម General) បន្ទាប់មក Response Headers បន្ទាប់មក Request Headers។
4. សម្រាប់ POST tab Payload (Chrome/Edge) ឬ tab Request (Firefox) បង្ហាញ body។

រឿងពីរដែលគួរបើក៖ ចុចខាងស្តាំលើក្បាល column នៅក្នុងបញ្ជី request ហើយបន្ថែម column Method និងធីក Preserve log នៅខាងលើ ដើម្បីកុំឲ្យបញ្ជីត្រូវបានសម្អាត នៅពេលការ submit form នាំអ្នកទៅទំព័រថ្មី។

អ្នកអភិវឌ្ឍន៍ចំណាយពេលច្រើននៅទីនេះ។ នៅពេលកម្មវិធីមួយ «មិនដំណើរការ» សំណួរដំបូងស្ទើរតែជានិច្ចគឺ៖ តើវាពិតជាបានផ្ញើ request អ្វី?

9. សាកល្បងដោយខ្លួនឯង

1. មើល request ផ្ទាល់ខ្លួនរបស់អ្នក។ រត់ curl https://httpbin.org/headers។ បន្ទាប់មកបើកអាសយដ្ឋានដដែលនៅក្នុង browser របស់អ្នក។ ប្រៀបធៀប header។ តើ browser ផ្ញើច្រើនជាងប៉ុន្មាន?

2. សាកល្បង method ផ្សេងទៀត។

   curl -X POST https://httpbin.org/post -d "name=Dara"
   curl -X DELETE https://httpbin.org/delete
   curl -X POST https://httpbin.org/post \
     -H "Content-Type: application/json" \
     -d '{"productId": 42, "quantity": 2}'
   

   Copy

   នៅក្នុងការឆ្លើយតបនីមួយៗ រកមើលកន្លែងដែល httpbin បង្ហាញ body ដែលវាបានទទួល។

3. សុំភាសាផ្សេង។ រត់ curl -I -H "Accept-Language: km" https://www.google.com ហើយបន្ទាប់មកម្តងទៀតជាមួយ en។ តើ response header ផ្លាស់ប្តូរទេ?

4. មើល form មួយ។ នៅលើ site ណាមួយដែលមានប្រអប់ស្វែងរក បើក DevTools → Network ធីក Preserve log ហើយស្វែងរកអ្វីមួយ។ រក request នោះ។ តើវាជា GET ឬ POST? តើពាក្យស្វែងរករបស់អ្នកទៅណា — URL ឬ body?

Request ត្រូវបានផ្ញើហើយ។ បន្ទាប់៖ អ្វីដែល server ផ្ញើត្រឡប់មកវិញ និងអត្ថន័យនៃលេខទាំងអស់នោះ ដូចជា 200 និង 404។