HTTP ба REST API-г энгийнээр ойлгох

Яагаад HTTP мессежийг уншиж сурах вэ?

Frontend “task нэм” гэсэн санааг backend ойлгохын тулд хоёулаа нэг гэрээтэй байх хэрэгтэй. Аль URL руу, ямар HTTP method-оор, ямар JSON явуулах вэ? Амжилттай үүссэн эсвэл task олдоогүйг response-оос яаж ялгах вэ?

HTTP нь client болон server хооронд resource дамжуулах application-layer protocol. REST API нь HTTP-ийн method, URL, status зэрэг ойлголтыг resource-д төвлөрүүлэн тогтвортой ашиглах design approach юм.

Mental model: дугтуйтай мессеж

HTTP request-ийг дараах дөрвөн асуулттай мессеж гэж төсөөл:

Хаашаа?  → URL / endpoint
Юу хийх? → HTTP method
Нөхцөл?  → headers
Ямар data? → body

Response мөн status, headers, body-той. Status code нь үр дүнгийн ангиллыг machine-readable байдлаар өгнө; response body нь task эсвэл safe error тайлбарыг өгч болно.

URL, endpoint, resource

URL нь resource-ийн хаяг. API-ийн тодорхой method болон path хүлээн авах цэгийг өдөр тутам endpoint гэж нэрлэдэг.

Task Manager-д task бол resource. Collection болон нэг item-ийг URL-аар ялгана:

/api/tasks          → task collection
/api/tasks/task_42  → нэг task

REST URL-д үйлдлийн verb давхардахгүй байх нь ихэвчлэн ойлгомжтой: POST /api/create-task гэхээс илүү POST /api/tasks. “Үүсгэх” санааг POST method өөрөө илэрхийлнэ.

HTTP method сонгох

| Зорилго | Method ба endpoint | Тайлбар | | --- | --- | --- | | Task жагсаах | GET /api/tasks | Resource-ийн representation уншина | | Task үүсгэх | POST /api/tasks | Collection-д шинэ resource нэмнэ | | Task-ийн хэсэг өөрчлөх | PATCH /api/tasks/{id} | Жишээ нь completed талбар | | Task устгах | DELETE /api/tasks/{id} | Тухайн resource-ийг устгана |

{id} бол placeholder. Бодит request-д /api/tasks/task_42 шиг утгаар солигдоно.

Request-ийн хэсгүүд

Method ба path

Эхний мөр request-ийн зорилгыг илэрхийлнэ:

POST /api/tasks HTTP/1.1

Headers

Headers нь body-оос тусдаа metadata. Эхлэгч түвшинд дараах хоёрыг танихад хангалттай:

• Content-Type: application/json — body JSON форматтайг хэлнэ.
• Accept: application/json — client JSON response хүлээж байгааг хэлнэ.

Authentication token зэрэг sensitive header-ийг log, screenshot, tutorial дотор задруулж болохгүй.

Request body

POST болон PATCH request өөрчлөх data-гаа body-д илгээж болно. JSON (JavaScript Object Notation) нь key-value бүтэцтэй, хэлнээс хамаарахгүй data format.

POST /api/tasks HTTP/1.1
Content-Type: application/json
Accept: application/json

{
  "title": "HTTP дасгалаа хийх"
}

Backend JSON parse хийсний дараа ч title-ийг runtime-д validation хийнэ. JSON зөв syntax-тай байна гэдэг business rule давсан гэсэн үг биш.

Response-ийн хэсгүүд

Task амжилттай үүссэн response:

HTTP/1.1 201 Created
Content-Type: application/json
Location: /api/tasks/task_42

{
  "id": "task_42",
  "title": "HTTP дасгалаа хийх",
  "completed": false
}

Response body нь client-д хэрэгтэй шинэ canonical state-ийг буцааж байна. Frontend өөрөө fake ID зохиохын оронд server-ийн үүсгэсэн ID-г ашиглана.

Энэ хичээлд хэрэгтэй status code

200 OK

Request амжилттай. GET /api/tasks task жагсаалт буцаах, PATCH шинэчлэгдсэн task буцаахад хэрэглэж болно.

201 Created

Шинэ resource амжилттай үүссэн. POST /api/tasks response-д тохиромжтой. Location header-аар шинэ resource-ийн URL өгч болно.

400 Bad Request

Client-ийн илгээсэн request боловсруулах боломжгүй. JSON syntax буруу, title хоосон, field-ийн төрөл буруу зэрэг validation error байж болно.

{
  "error": {
    "code": "INVALID_TASK_TITLE",
    "message": "Task-ийн гарчиг хоосон байж болохгүй."
  }
}

404 Not Found

Хүссэн resource олдсонгүй. PATCH /api/tasks/task_missing үед ID хэлбэр зөв ч task байхгүй бол 404 тохиромжтой.

500 Internal Server Error

Server санаандгүй нөхцөлтэй тулгарсан. Client алдаагаа засаад шийдэх 400-гаас ялгаатай. Database connection string, stack trace зэрэг дотоод мэдээллийг body-д өгөхгүй; server талд аюулгүй log хийнэ.

Complete task request зохиох

Task-ийн зөвхөн completed талбарыг өөрчлөх тул PATCH сонгож болно:

PATCH /api/tasks/task_42 HTTP/1.1
Content-Type: application/json

{
  "completed": true
}

Амжилттай response:

HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": "task_42",
  "title": "HTTP дасгалаа хийх",
  "completed": true
}

Backend дараахыг шалгана:

1. ID route parameter зөв хэлбэртэй юу?
2. Body JSON мөн үү?
3. completed boolean мөн үү?
4. Task байна уу?
5. Шинэчлэх эрх байна уу?
6. Database update амжилттай юу?

API contract тогтвортой байхын ач холбогдол

Frontend болон backend тусдаа хөгжиж болно. Тэд method, path, request body, response body, error format дээр тохирсон бол implementation-ээ бие даан сайжруулж чадна. Contract өөрчлөхдөө хуучин client-д нөлөөлөх эсэхийг тооцно.

API “RESTful” гэж нэрлэгдсэн эсэхээс илүү:

• resource нэр ойлгомжтой;
• method semantics зөв;
• validation тодорхой;
• status code утгатай;
• error body тогтвортой;
• authorization server талд;
• нууц мэдээлэл response-д байхгүй

байх нь бодит системд чухал.

Түгээмэл алдаа

• Endpoint бүрийг verb-ээр нэрлээд HTTP method-ийн утгыг давхардуулах
• GET request body-д update data илгээх
• Бүх амжилтад, алдаанд 200 буцаах
• JSON parse амжилттайг validation амжилттайтай андуурах
• Client-ийн өгсөн ID, role, price зэрэгт шалгалтгүй итгэх
• 500 response-д stack trace болон credential задруулах
• DELETE амжилттай бол response body заавал байх ёстой гэж бодох

Мэдлэгээ шалгах

Дүгнэлт

HTTP request нь method, URL/path, headers, optional body-той; response нь status, headers, optional body-той. REST API resource-ээ URL-аар нэрлэж, GET, POST, PATCH, DELETE semantics-ийг тогтвортой ашиглана. Status code болон structured JSON body-г зөв хослуулснаар frontend амжилт, input error, missing resource, server error-ийг найдвартай ялгана.