HATEOAS અને Richardson Maturity Model શું છે?

Question

IT Interview Practice · Accepted Answer

**Richardson Maturity Model (RMM)** API કેટલી "RESTful" છે તેને ચાર levels માં ગ્રેડ કરે છે, અને **HATEOAS** એ સર્વોચ્ચ level છે — એ constraint જે મોટા ભાગના લોકો છોડી દે છે.

## ચાર levels

```text
Level 0 — "The Swamp of POX": one URI, one method (RPC over HTTP).
          POST /api  { "action": "getUser", "id": 42 }
Level 1 — Resources: many URIs, but still one verb.
          POST /users/42  ,  POST /users/42/delete
Level 2 — HTTP Verbs: proper methods + status codes (where most "REST" APIs live).
          GET /users/42 → 200 ,  DELETE /users/42 → 204
Level 3 — Hypermedia Controls (HATEOAS): responses link to what you can do next.
```

મોટા ભાગની production "REST" APIs **Level 2** છે — સાચા resources, methods, અને status codes. તે સામાન્ય રીતે પૂરતું સારું છે, અને તે સંપૂર્ણપણે વાજબી લક્ષ્ય છે.

## HATEOAS (Level 3)

**HATEOAS** = *Hypermedia As The Engine Of Application State*. વિચાર: response માં **links** હોય છે જે client ને કહે છે કે આગળ કઈ actions ઉપલબ્ધ છે, જેથી client URLs ને hardcode કરવાને બદલે links અનુસરીને API ને navigate કરે — જેમ માણસ દરેક URL યાદ રાખવાને બદલે web page પરની links અનુસરે છે.

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

{
  "id": 1001,
  "status": "pending",
  "total": 250,
  "_links": {
    "self":   { "href": "/orders/1001" },
    "pay":    { "href": "/orders/1001/payment", "method": "POST" },
    "cancel": { "href": "/orders/1001/cancel",  "method": "POST" }
  }
}
```

કારણ કે order `pending` છે, server `pay` અને `cancel` links આપે છે. એકવાર paid થાય, એ links અદૃશ્ય થાય છે અને `refund` link દેખાઈ શકે છે — **server state transitions ચલાવે છે**, અને client તેને અપાયેલ કોઈપણ links ને ફક્ત અનુસરે છે.

## તે શા માટે દુર્લભ છે

વચન છે decoupling: clients URLs ને hardcode કરતા નથી, તેથી server તેમને મુક્તપણે પુનર્ગઠિત કરી શકે છે. વ્યવહારમાં મોટા ભાગના clients તોય hardcode કરે છે, HATEOAS વાસ્તવિક જટિલતા ઉમેરે છે, અને formats ક્યારેય સંપૂર્ણ પ્રમાણભૂત થયા નથી (HAL, JSON:API, Siren બધા સ્પર્ધા કરે છે). વળતર ભાગ્યે જ ખર્ચને ન્યાયી ઠેરવે છે.

## આ શા માટે મહત્વનું છે

આ classic senior-સ્તરનો પ્રશ્ન છે કારણ કે તે **REST ને મૂળ વ્યાખ્યા પ્રમાણે સમજતા** લોકોને "REST" ને છૂટથી "HTTP પર JSON" તરીકે વાપરતાઓથી અલગ પાડે છે. મૂલ્યવાન સૂઝ ચાર levels ગોખવી નથી — તે એ ન્યાયબુદ્ધિ છે કે **Level 2 એ વ્યવહારુ sweet spot છે** એ કહેવું જ્યારે એ જાણવું કે સાચું REST (Fielding ની વ્યાખ્યા) HATEOAS ની *જરૂર છે*, અને *ઉદ્યોગ મોટે ભાગે તેને શા માટે અવગણે છે* તે સમજાવવા સક્ષમ હોવું: decoupling ફાયદો વાસ્તવિક છે પણ ભાગ્યે જ સાકાર થાય છે કારણ કે clients તોય URLs hardcode કરે છે, અને ઉમેરાયેલ જટિલતા વત્તા સ્પર્ધા કરતા hypermedia formats સામાન્ય APIs માટે વળતર આપતા નથી. HATEOAS *શું છે* તે તમે જાણો છો તે દર્શાવવું, નક્કર state-driven-links ઉદાહરણ બતાવવું, અને cost/benefit વિશે પ્રામાણિકપણે દલીલ કરવી — દરેક API એ Level 3 હોવું જ જોઈએ એવો હઠાગ્રહ કરવાને બદલે — એ બરાબર સંતુલિત, અનુભવ-આધારિત ન્યાયબુદ્ધિ છે જે interviewers શોધે છે.

ચાર levels

HATEOAS (Level 3)

તે શા માટે દુર્લભ છે

આ શા માટે મહત્વનું છે

સંબંધિત પ્રશ્નો