რა არის REST და რომელია მისი მთავარი შეზღუდვები?

Question

IT Interview Practice · Accepted Answer

**REST** (Representational State Transfer) არის **არქიტექტურული სტილი** ქსელური აპლიკაციებისთვის, განსაზღვრული Roy Fielding-ის მიერ. ის არ არის პროტოკოლი ან სტანდარტი — ის არის **შეზღუდვების** ნაკრები, რომელთა დაცვისას API ხდება მასშტაბირებადი, cache-ირებადი და ადვილად განვითარებადი. „RESTful" API ყველაფერს **resource-ებად** მოდელირებს (user-ები, order-ები, product-ები), იდენტიფიცირებულს URI-ებით, და მართავს მათ სტანდარტული HTTP method-ებით.

## ძირითადი შეზღუდვები

- **Client–server** — გამოყავით UI (client) მონაცემთა შენახვისგან (server), რომ თითოეული დამოუკიდებლად განვითარდეს.
- **Stateless** — ყოველი request ატარებს მისი დამუშავებისთვის საჭირო მთელ ინფორმაციას; server **არ ინახავს client-ის session state-ს** request-ებს შორის. ნებისმიერ server-ს შეუძლია ნებისმიერი request-ის დამუშავება, რაც ჰორიზონტალურ მასშტაბირებას ამარტივებს.
- **Cacheable** — response-ები აცხადებენ, შეიძლება თუ არა მათი cache-ირება, რაც client-ებსა და proxy-ებს მათ ხელახლა გამოყენების საშუალებას აძლევს.
- **Uniform interface** — განმსაზღვრელი შეზღუდვა: resource-ები იდენტიფიცირდება URI-ებით, იმართება representation-ებით (ჩვეულებრივ JSON), message-ები თვითაღწერითია და hypermedia link-ები client-ს წარმართავენ.
- **Layered system** — proxy-ები, gateway-ები და load balancer-ები client-სა და server-ს შორის გამჭვირვალედ შეიძლება იჯდნენ.
- **Code-on-demand** (არასავალდებულო) — server-ებმა შეიძლება გამოგზავნონ შესრულებადი კოდი (მაგ. JavaScript).

## Resource-ზე ორიენტირებული request

```http
GET /users/42 HTTP/1.1
Host: api.example.com
Accept: application/json
```

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

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

URI `/users/42` ასახელებს resource-ს; `GET` არის ქმედება; JSON არის representation. ეს კომბინაცია — არსებითი სახელები path-ში, ზმნები HTTP method-ებად — REST-ის გული.

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

REST დომინანტი სტილია web API-ებისთვის, ამიტომ ინტერვიუერები ამ კითხვას იყენებენ იმის შესამოწმებლად, გესმით თუ არა *რატომ* მუშაობს ის და არა უბრალოდ იმის, რომ მისი დაწერა შეგიძლიათ. პრაქტიკაში ორი ყველაზე მნიშვნელოვანი შეზღუდვაა **statelessness** (ყოველი request თვითკმარია, ასე რომ load balancer-ის უკან ნებისმიერი რაოდენობის server-ის დაყენება და ჰორიზონტალურად მასშტაბირება შეგიძლიათ sticky session-ების გარეშე) და **uniform interface** (პროგნოზირებადი, resource-ზე ორიენტირებული URL-ები პლუს სტანდარტული HTTP method-ები და status code-ები, რაც ნიშნავს, რომ client-ებს არ სჭირდებათ ინდივიდუალური ლოგიკა თითო endpoint-ზე). ძლიერი პასუხი შეზღუდვებს კონკრეტულ სარგებელს უკავშირებს — statelessness მასშტაბირებას აძლევს, cacheability დატვირთვას ამცირებს, layered system CDN-ებისა და gateway-ების ჩასმის საშუალებას იძლევა — და აღნიშნავს, რომ „REST" API-ების უმეტესობა პრაგმატულია და არა სრულად RESTful (ცოტანი ახორციელებენ HATEOAS-ს). ამ შეზღუდვების გაგება საფუძველია ყოველი სხვა REST დიზაინის გადაწყვეტილებისთვის, status code-ების არჩევიდან versioning-ამდე.

ძირითადი შეზღუდვები

Resource-ზე ორიენტირებული request

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

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