HATEOAS र Richardson Maturity Model भनेको के हो?

Question

IT Interview Practice · Accepted Answer

**Richardson Maturity Model (RMM)** ले एउटा API कति "RESTful" छ भन्ने कुरालाई चार तहमा श्रेणीकरण गर्छ, र **HATEOAS** सबैभन्दा माथिल्लो तह हो — धेरैजसो मानिसले छोड्ने constraint।

## चार तह

```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" API हरू **Level 2** मा छन् — सही resource, method, र status code। त्यो सामान्यतया पर्याप्त राम्रो हुन्छ, र यो पूर्ण रूपमा उचित लक्ष्य हो।

## HATEOAS (Level 3)

**HATEOAS** = *Hypermedia As The Engine Of Application State*। विचार: एउटा response मा **link** हरू समावेश हुन्छन् जसले client लाई अब कुन action उपलब्ध छ भन्छन्, त्यसैले client ले URL hardcode गर्नुको सट्टा link पछ्याएर API navigate गर्छ — हरेक URL घोकाउनुको सट्टा web page मा link पछ्याउने मानिसजस्तै।

```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` link प्रस्ताव गर्छ। एक पटक paid भएपछि, ती link हराउँछन् र एउटा `refund` link देखिन सक्छ — **server ले state transition चलाउँछ**, र client ले जे link दिइन्छ त्यही पछ्याउँछ।

## यो किन विरलै हुन्छ

वाचा भनेको decoupling हो: client हरूले URL hardcode गर्दैनन्, त्यसैले server ले तिनलाई स्वतन्त्र रूपमा पुनर्संरचना गर्न सक्छ। व्यवहारमा धेरैजसो client जसरी पनि hardcode गर्छन्, HATEOAS ले वास्तविक जटिलता थप्छ, र format हरू कहिल्यै पूर्ण रूपमा standardize भएनन् (HAL, JSON:API, Siren सबै प्रतिस्पर्धा गर्छन्)। प्रतिफलले विरलै लागत औचित्य ठहराउँछ।

## यो किन महत्त्वपूर्ण छ

यो एउटा उत्कृष्ट senior-स्तरको प्रश्न हो किनभने यसले **REST लाई मूल रूपमा परिभाषित गरिए अनुसार बुझ्ने** मानिसहरूलाई "JSON over HTTP" भन्ने अर्थमा "REST" लाई ढिलो प्रयोग गर्नेहरूबाट छुट्याउँछ। मूल्यवान अन्तर्दृष्टि चार तह रटाउनु होइन — यो **Level 2 व्यावहारिक sweet spot हो** भन्ने निर्णय गर्ने विवेक हो, साथै साँचो REST (Fielding को परिभाषा) लाई HATEOAS *चाहिन्छ* भन्ने थाहा हुनु, र *उद्योगले किन धेरैजसो यसलाई बेवास्ता गर्छ* भनेर व्याख्या गर्न सक्नु: decoupling फाइदा वास्तविक छ तर विरलै साकार हुन्छ किनभने client हरू जसरी पनि URL hardcode गर्छन्, र थपिएको जटिलता र प्रतिस्पर्धी hypermedia format विशिष्ट API का लागि लाभदायक हुँदैनन्। तपाईंलाई HATEOAS के *हो* थाहा छ, एउटा ठोस state-चालित-link उदाहरण देखाउन सक्नुहुन्छ, र लागत/लाभबारे इमानदारीपूर्वक तर्क गर्न सक्नुहुन्छ भन्ने देखाउनु — हरेक API Level 3 हुनैपर्छ भनेर हठपूर्वक जोड दिनुको सट्टा — ठ्याक्कै त्यही सन्तुलित, अनुभव-आधारित विवेक हो जुन interviewer हरू खोज्दैछन्।

चार तह

HATEOAS (Level 3)

यो किन विरलै हुन्छ

यो किन महत्त्वपूर्ण छ

सम्बन्धित प्रश्नहरू