როგორ აისახება HTTP method-ები CRUD-ზე და რას ნიშნავს safe და idempotent?

Question

IT Interview Practice · Accepted Answer

REST იყენებს სტანდარტულ **HTTP method-ებს** როგორც ზმნებს, რომლებიც resource-ებზე მოქმედებენ. გავრცელებული ასახვა **CRUD-ზე** (Create, Read, Update, Delete) ასეთია:

| CRUD | Method | ტიპური გამოყენება |
|------|--------|-------------|
| Create | `POST` | ახალი resource-ის დამატება კოლექციაში |
| Read | `GET` | resource-ის ან სიის მიღება |
| Update (სრული) | `PUT` | resource-ის სრულად ჩანაცვლება |
| Update (ნაწილობრივი) | `PATCH` | ზოგიერთი ველის ცვლილება |
| Delete | `DELETE` | resource-ის წაშლა |

## მაგალითები

```http
POST /users HTTP/1.1
Content-Type: application/json

{ "name": "Ann", "email": "ann@example.com" }
```

```http
HTTP/1.1 201 Created
Location: /users/42

{ "id": 42, "name": "Ann", "email": "ann@example.com" }
```

`PUT /users/42` აგზავნის **მთელ** representation-ს და ანაცვლებს მას; `PATCH /users/42` აგზავნის **მხოლოდ შესაცვლელ ველებს** (მაგ. `{ "email": "new@example.com" }`).

## Safe vs idempotent

ეს ორი განსხვავებული თვისებაა:

- **Safe** — method **არ ცვლის** server-ის state-ს (მხოლოდ წაკითხვა). `GET`, `HEAD`, `OPTIONS` safe-ია.
- **Idempotent** — **იმავე request-ის N-ჯერ** გაკეთებას იგივე ეფექტი აქვს, რაც ერთხელ გაკეთებას. `GET`, `PUT`, `DELETE`, `HEAD` idempotent-ია.

```text
Method   Safe?   Idempotent?
GET      yes     yes
HEAD     yes     yes
PUT      no      yes      (replacing with the same body twice = same result)
DELETE   no      yes      (deleting twice = still deleted)
PATCH    no      no*      (depends on the patch; not guaranteed)
POST     no      no       (posting twice usually creates two resources)
```

## რატომ არის ეს მნიშვნელოვანი

ინტერვიუერები ამას სვამენ იმის სანახავად, გესმით თუ არა HTTP-ის სემანტიკა საკმარისად კარგად საიმედო API-ების ასაშენებლად. safe/idempotent განსხვავება არ არის აკადემიური: ის პირდაპირ განსაზღვრავს, რისი უფლება აქვთ client-ებს, proxy-ებსა და CDN-ებს. **Safe** method-ები შეიძლება თავისუფლად cache-ირდეს და prefetch-ირდეს; **idempotent** method-ები შეიძლება **ავტომატურად გამეორდეს (retry)** ქსელური timeout-ის შემდეგ side effect-ების დუბლირების რისკის გარეშე — რის გამოც client-ს შეუძლია უსაფრთხოდ გაიმეოროს `PUT` ან `DELETE`, მაგრამ ფრთხილად უნდა იყოს `POST`-ის გამეორებისას (მან შეიძლება ორი order შექმნას). კლასიკური შეცდომაა `GET`-ის გამოყენება side effect-ის გამოსაწვევად (მაგ. `GET /users/42/delete`), რაც caching-ს ანგრევს და crawler-ებს მონაცემების შემთხვევით შეცვლის საშუალებას აძლევს. სწორი method-ის არჩევა — და მისი safe/idempotent კონტრაქტის დაცვა — არის ის, რაც API-ს პროგნოზირებადს და მის გარშემო tooling-ის ასაშენებლად უსაფრთხოს ხდის.

Create	`POST`	ახალი resource-ის დამატება კოლექციაში
Read	`GET`	resource-ის ან სიის მიღება
Update (სრული)	`PUT`	resource-ის სრულად ჩანაცვლება
Update (ნაწილობრივი)	`PATCH`	ზოგიერთი ველის ცვლილება
Delete	`DELETE`	resource-ის წაშლა

მაგალითები

Safe vs idempotent

რატომ არის ეს მნიშვნელოვანი

დაკავშირებული კითხვები