REST API എങ്ങനെ നിർമ്മിക്കാം: ഡിസൈൻ, സുരക്ഷ, വിന്യാസം
REST API നിർമ്മിക്കാൻ, നിങ്ങളുടെ ആപ്പ് നിയന്ത്രിക്കുന്ന റിസോഴ്സുകൾ (ഉപയോക്താക്കൾ, ഓർഡറുകൾ, ബുക്കിംഗുകൾ) പട്ടികപ്പെടുത്തുക, ഓരോന്നിനും /orders പോലുള്ള ഒരു URL നൽകുക, പ്രവർത്തനങ്ങൾക്ക് HTTP രീതികൾ ഉപയോഗിക്കുക: വായിക്കാൻ GET, സൃഷ്ടിക്കാൻ POST, മാറ്റാൻ PATCH, നീക്കം ചെയ്യാൻ DELETE. അർത്ഥവത്തായ സ്റ്റാറ്റസ് കോഡുകളോടെ JSON തിരികെ നൽകുക, ഓരോ ഇൻപുട്ടും വാലിഡേറ്റ് ചെയ്യുക, സെർവറിൽ ഓതന്റിക്കേഷനും ഓരോ റെക്കോർഡിനുമുള്ള അനുമതി പരിശോധനയും ഉറപ്പാക്കുക, ലിസ്റ്റുകൾ പേജ് ചെയ്യുക. പിന്നെ എൻഡ്പോയിന്റുകൾ ഡോക്യുമെന്റ് ചെയ്ത്, HTTPS-ന് പിന്നിൽ API വിന്യസിക്കുക.
ഈ ഗൈഡ് ഡിസൈൻ തീരുമാനങ്ങൾ, ഒരു കൂട്ടം റൂട്ടുകൾ, AI ആപ്പ് ബിൽഡറിനുള്ള പ്രോംപ്റ്റുകൾ, സുരക്ഷാ പിഴവുകൾക്ക് കാരണമാകുന്ന തെറ്റുകൾ എന്നിവ കൈകാര്യം ചെയ്യുന്നു. API-കൾ പുതിയതാണെങ്കിൽ എന്താണ് API എന്നതിൽ നിന്ന് ആരംഭിക്കുക.
REST API എപ്പോൾ വേണം
- നിങ്ങളുടെ വെബ് ഫ്രണ്ട്എൻഡിന് സെർവറിൽ നിന്ന് ഡാറ്റ സേവ് ചെയ്യുകയും ലോഡ് ചെയ്യുകയും വേണം
- ഒരു മൊബൈൽ ആപ്പ്, പങ്കാളി അല്ലെങ്കിൽ ഓട്ടോമേഷൻ ടൂളിന് നിങ്ങളുടെ ഡാറ്റയിലേക്ക് ആക്സസ് വേണം
- മറ്റ് സേവനങ്ങൾ നിങ്ങൾക്ക് ഇവന്റുകൾ അയയ്ക്കുന്നു (വെബ്‌ഹുക്കുകൾ)
- ഫ്രണ്ട്എൻഡും ബാക്കെൻഡ് ടീമുകളും തമ്മിൽ ജോലി വിഭജിക്കുന്നു
REST ഏറ്റവും സാധാരണമായ ശൈലിയാണ്, പക്ഷേ ഏക ശൈലിയല്ല. ഒരൊറ്റ വഴക്കമുള്ള ക്വറി എൻഡ്പോയിന്റ് എപ്പോൾ യോജിക്കുമെന്ന് REST vs GraphQL വിശദീകരിക്കുന്നു.
ആദ്യം ഡിസൈൻ ചെയ്യുക: റിസോഴ്സുകളും റൂട്ടുകളും
നിങ്ങളുടെ ആപ്പിലെ നാമങ്ങളും ആളുകൾ അവയോട് ചെയ്യുന്നതും എഴുതുക. ലളിതമായ ഒരു ബുക്കിംഗ് ആപ്പിന്:
| രീതി | റൂട്ട് | ചെയ്യുന്നത് | വിജയ കോഡ് |
|---|---|---|---|
GET | /api/bookings | വിളിക്കുന്നയാളുടെ ബുക്കിംഗുകൾ പട്ടികപ്പെടുത്തുക (പേജ് ചെയ്തത്) | 200 |
POST | /api/bookings | ഒരു ബുക്കിംഗ് സൃഷ്ടിക്കുക | 201 |
GET | /api/bookings/{id} | ഒരു ബുക്കിംഗ് നേടുക | 200 |
PATCH | /api/bookings/{id} | ചില ഫീൽഡുകൾ മാറ്റുക | 200 |
DELETE | /api/bookings/{id} | ബുക്കിംഗ് റദ്ദാക്കുക | 204 |
GET | /api/health | മോണിറ്ററിംഗിനുള്ള ഹെൽത്ത് ചെക്ക് | 200 |
ഇവ create, read, update, delete ആയി മാപ്പ് ചെയ്യുന്നു; CRUD എന്താണെന്ന് കാണുക. പിന്തുടരേണ്ട ചില കൺവെൻഷനുകൾ:
- URL-ൽ ബഹുവചന നാമങ്ങൾ, ക്രിയകളില്ല:
/getBookingsഅല്ല,/bookings. - ഉടമസ്ഥത വ്യക്തമാക്കുമ്പോൾ മാത്രം ഒരു ലെവൽ നെസ്റ്റ് ചെയ്യുക:
/bookings/{id}/notes. - CRUD അല്ലാത്ത പ്രവർത്തനങ്ങൾ സബ്-റിസോഴ്സുകളാകാം:
POST /bookings/{id}/cancelഒരു മാജിക് PATCH-നേക്കാൾ വ്യക്തമാണ്. - ഫീൽഡുകൾക്ക് സ്ഥിരമായ പേരുകൾ, ഉദാഹരണത്തിന് എല്ലായിടത്തും
created_at.
സ്റ്റാറ്റസ് കോഡുകളും പിശകുകളും
ടെക്സ്റ്റ് പാഴ്‌സ് ചെയ്യാതെ എന്ത് സംഭവിച്ചെന്ന് ക്ലയന്റുകൾക്ക് അറിയാൻ സ്റ്റാൻഡേർഡ് HTTP കോഡുകൾ ഉപയോഗിക്കുക:
| കോഡ് | അർത്ഥം | എപ്പോൾ ഉപയോഗിക്കണം |
|---|---|---|
| 200 | OK | വിജയകരമായ വായന അല്ലെങ്കിൽ അപ്ഡേറ്റ് |
| 201 | Created | POST വഴി എന്തെങ്കിലും സൃഷ്ടിച്ചപ്പോൾ |
| 204 | No Content | തിരികെ നൽകാൻ ഒന്നുമില്ലാത്ത വിജയം |
| 400 | Bad Request | ഇൻപുട്ട് വാലിഡേഷൻ പരാജയപ്പെട്ടു |
| 401 | Unauthorized | ലോഗിൻ ചെയ്തിട്ടില്ല അല്ലെങ്കിൽ ടോക്കൺ തെറ്റാണ് |
| 403 | Forbidden | ലോഗിൻ ചെയ്തിട്ടുണ്ട്, പക്ഷേ അനുവാദമില്ല |
| 404 | Not Found | ഇല്ല, അല്ലെങ്കിൽ അത് നിലനിൽക്കുന്നതായി വിളിക്കുന്നയാൾ അറിയരുത് |
| 409 | Conflict | ഡൂപ്ലിക്കേറ്റ്, അല്ലെങ്കിൽ സ്ലോട്ട് ഇതിനകം ബുക്ക് ചെയ്തത് |
| 429 | Too Many Requests | റേറ്റ് ലിമിറ്റ് എത്തി |
| 500 | Server Error | നിങ്ങളുടെ ഭാഗത്ത് എന്തോ തകർന്നു |
പിശകുകൾ ഒരേ JSON രൂപത്തിൽ തിരികെ നൽകുക, ഉദാഹരണത്തിന് {"error": {"code": "slot_taken", "message": "ആ സമയം ഇനി ലഭ്യമല്ല."}}. പ്രതികരണങ്ങളിൽ ഒരിക്കലും സ്റ്റാക്ക് ട്രേസോ ഡാറ്റാബേസ് പിശകുകളോ ഉൾപ്പെടുത്തരുത്.
ഓപ്ഷനുകളും വിട്ടുവീഴ്ചകളും
| തീരുമാനം | ലളിതമായ തിരഞ്ഞെടുപ്പ് | ബദൽ |
|---|---|---|
| API എവിടെ ജീവിക്കുന്നു | നിങ്ങളുടെ വെബ് ഫ്രെയിംവർക്കിലെ API റൂട്ടുകൾ | ഒന്നിലധികം ക്ലയന്റുകൾക്കോ വ്യത്യസ്ത ഭാഷയ്ക്കോ ഉപകാരപ്രദമായ പ്രത്യേക API സേവനം |
| ഓതന്റിക്കേഷൻ | നിങ്ങളുടെ സ്വന്തം വെബ് ആപ്പിനുള്ള സെഷൻ കുക്കികൾ | മൊബൈൽ ആപ്പുകൾക്കും മൂന്നാം കക്ഷികൾക്കുമുള്ള ടോക്കണുകൾ (ബെയറർ ടോക്കണുകൾ അല്ലെങ്കിൽ API കീകൾ) |
| പേജിനേഷൻ | ?page=2&limit=20 | കഴ്സർ അടിസ്ഥാനമാക്കിയുള്ളത് (?after=...), വലുതും മാറുന്നതുമായ ലിസ്റ്റുകൾക്ക് സ്ഥിരതയുള്ളത് |
| വേർഷനിംഗ് | ആരും പുറത്തുനിന്ന് ആശ്രയിക്കുന്നതുവരെ ഒന്നുമില്ല | മറ്റുള്ളവർ ആശ്രയിച്ചാൽ പാതയിൽ /v1/ |
| ഡോക്സ് | റൂട്ടുകൾ പട്ടികപ്പെടുത്തുന്ന ഒരു README | OpenAPI സ്പെക്, ഇതിൽ നിന്ന് ഇന്ററാക്ടീവ് ഡോക്സും ക്ലയന്റ് കോഡും ടൂളുകൾക്ക് ഉണ്ടാക്കാം |
ഘട്ടം ഘട്ടമായി
- റിസോഴ്സുകളും റൂട്ടുകളും പട്ടികപ്പെടുത്തുക മുകളിൽ പറഞ്ഞതുപോലെ, ഓരോന്നിനും ആർക്ക് വിളിക്കാം എന്നതും ഉൾപ്പെടെ.
- ഡാറ്റ മോഡൽ ചെയ്യുക നിങ്ങളുടെ ഡാറ്റാബേസിൽ ആവശ്യമായ ഫീൽഡുകളും ബന്ധങ്ങളും സഹിതം.
- ആദ്യം റീഡ് റൂട്ടുകൾ നിർമ്മിക്കുക, പിന്നെ create, update, delete.
- ഓരോ റൈറ്റിലും ഇൻപുട്ട് വാലിഡേറ്റ് ചെയ്യുക ഒരു സ്കീമ ലൈബ്രറി ഉപയോഗിച്ച്: ആവശ്യമായ ഫീൽഡുകൾ, തരങ്ങൾ, നീളങ്ങൾ, അനുവദനീയ മൂല്യങ്ങൾ. അജ്ഞാത ഫീൽഡുകൾ നിരസിക്കുക.
- ഓതന്റിക്കേഷൻ ചേർക്കുക, പിന്നെ ഓരോ റെക്കോർഡിനുമുള്ള അധികാരപ്പെടുത്തൽ:
/bookings/42ലോഡ് ചെയ്യുമ്പോൾ ആരെങ്കിലും ലോഗിൻ ചെയ്തിട്ടുണ്ടോ എന്ന് മാത്രമല്ല, ബുക്കിംഗ് 42 വിളിക്കുന്നയാളുടേതാണോ എന്നും പരിശോധിക്കണം. - എല്ലാ ലിസ്റ്റും പേജ് ചെയ്യുക, പേജ് വലുപ്പം പരിധിയിൽ നിർത്തുക.
- ലോഗിനും ചെലവേറിയ റൂട്ടുകളും റേറ്റ്-ലിമിറ്റ് ചെയ്യുക. റേറ്റ് ലിമിറ്റിംഗ് കാണുക.
- CORS കോൺഫിഗർ ചെയ്യുക മറ്റ് ഡൊമെയ്‌നുകളിലുള്ള ബ്രൗസറുകൾ API വിളിക്കേണ്ടിവന്നാൽ മാത്രം, ആ ഒറിജിനുകൾ വ്യക്തമായി പട്ടികപ്പെടുത്തി. CORS പിശകുകൾ എങ്ങനെ പരിഹരിക്കാം നിങ്ങൾ കാണുന്ന പിശകുകൾ വിശദീകരിക്കുന്നു.
- ഓരോ റൂട്ടിനും ഡോക്സും ടെസ്റ്റുകളും എഴുതുക, പരാജയ കേസുകൾ ഉൾപ്പെടെ.
- വിന്യസിക്കുക, രഹസ്യങ്ങൾ എൻവയോൺമെന്റ് വേരിയബിളുകളിലും HTTPS, ലോഗുകൾ, ഹെൽത്ത് ചെക്ക് എന്നിവയോടെയും.
നിങ്ങളുടെ AI ബിൽഡറിനുള്ള പ്രോംപ്റ്റുകൾ
സ്കാഫോൾഡ്:
ബുക്കിംഗുകൾക്കായി ഈ റൂട്ടുകളോടെ ഒരു REST API സൃഷ്ടിക്കുക: GET /api/health, GET /api/bookings (പേജ് ചെയ്തത്, ഒരു പേജിൽ പരമാവധി 50), POST /api/bookings, GET /api/bookings/:id, PATCH /api/bookings/:id, DELETE /api/bookings/:id. ഡാറ്റ ഞങ്ങളുടെ ഡാറ്റാബേസിൽ സൂക്ഷിക്കുക. സ്കീമ ലൈബ്രറി ഉപയോഗിച്ച് റിക്വസ്റ്റ് ബോഡികൾ വാലിഡേറ്റ് ചെയ്ത് അജ്ഞാത ഫീൽഡുകൾ നിരസിക്കുക. പിശകുകൾ {"error": {"code", "message"}} ആയി JSON-ൽ ശരിയായ സ്റ്റാറ്റസ് കോഡുകളോടെ (400, 401, 403, 404, 409) തിരികെ നൽകുക. രഹസ്യങ്ങൾ എൻവയോൺമെന്റ് വേരിയബിളുകളിൽ സൂക്ഷിക്കുക.
സുരക്ഷ:
ബുക്കിംഗ് റൂട്ടുകളിലെല്ലാം ലോഗിൻ ആവശ്യപ്പെടുക. ഓരോ റീഡ്, അപ്ഡേറ്റ്, ഡിലീറ്റിലും ബുക്കിംഗ് നിലവിലെ ഉപയോക്താവിന്റേതാണെന്ന് സെർവറിൽ പരിശോധിക്കുക; അല്ലെങ്കിൽ 404 നൽകുക. അഭ്യർത്ഥന ബോഡിയിൽ നിന്ന് ഒരിക്കലും ഉപയോക്തൃ ID-കളോ റോളുകളോ സ്വീകരിക്കരുത്. POST /api/bookings ഒരു ഉപയോക്താവിന് മിനിറ്റിൽ 20 ആയി റേറ്റ്-ലിമിറ്റ് ചെയ്യുക. സെർവറിൽ പിശകുകൾ ലോഗ് ചെയ്യുക, സ്റ്റാക്ക് ട്രേസുകൾ തിരികെ നൽകാതെ.
ഡോക്സ്:
ഈ റൂട്ടുകളുടെ ഒരു OpenAPI വിവരണവും ഓരോന്നിനും ഉദാഹരണ അഭ്യർത്ഥനകളും പ്രതികരണങ്ങളും ഉള്ള ഒരു ചെറിയ README എഴുതുക.
നിങ്ങളുടെ API പരീക്ഷിക്കൽ
ഫ്രണ്ട്എൻഡിന് പുറത്തുനിന്ന് പരീക്ഷിക്കുക, കാരണം ആക്രമണകാരികൾ അങ്ങനെ ചെയ്യും:
- ഓരോ റൂട്ടും സാധുവായ ഇൻപുട്ടിൽ പ്രവർത്തിച്ച് ഡോക്യുമെന്റ് ചെയ്ത രൂപവും കോഡും തിരികെ നൽകുന്നു
- ഇല്ലാത്തതോ തെറ്റായതോ ആയ ഫീൽഡുകൾ വ്യക്തമായ സന്ദേശത്തോടെ 400 തിരികെ നൽകുന്നു
- സംരക്ഷിത ഓരോ റൂട്ടിലും ടോക്കൺ ഇല്ലെങ്കിൽ 401 തിരികെ നൽകുന്നു
- ഉപയോക്താവ് A, ഉപയോക്താവ് B-യുടെ റെക്കോർഡ് ID വഴി ആവശ്യപ്പെട്ടാൽ 404 അല്ലെങ്കിൽ 403 ലഭിക്കുന്നു
- ലിസ്റ്റുകൾ പേജ് ചെയ്തിരിക്കുന്നു; വലിയ
limitപരിധിയിൽ നിൽക്കുന്നു - ഡൂപ്ലിക്കേറ്റ് അല്ലെങ്കിൽ വൈരുദ്ധ്യമുള്ള സൃഷ്ടികൾ 500 അല്ല, 409 നൽകുന്നു
- റേറ്റ് ലിമിറ്റുകൾ 429 നൽകുന്നു
- പിശക് പ്രതികരണങ്ങളിൽ സ്റ്റാക്ക് ട്രേസ്, SQL അല്ലെങ്കിൽ രഹസ്യങ്ങൾ ഇല്ല
- CORS ഉദ്ദേശിച്ച ഒറിജിനുകൾക്ക് മാത്രം അനുവദിക്കുന്നു
സാധാരണ തെറ്റുകൾ
- ലോഗിൻ പരിശോധിക്കുന്നു, ഉടമസ്ഥത പരിശോധിക്കുന്നില്ല. ഏറ്റവും സാധാരണമായ API പിഴവ്: ID മാറ്റി ഏത് ലോഗിൻ ചെയ്ത ഉപയോക്താവിനും ഏത് റെക്കോർഡും വായിക്കാം.
- ക്ലയന്റിനെ വിശ്വസിക്കുന്നത്. അഭ്യർത്ഥന ബോഡിയിലെ വിലകൾ, റോളുകൾ, ഉപയോക്തൃ ID-കൾ എഡിറ്റ് ചെയ്യാം.
- മുഴുവൻ ഡാറ്റാബേസ് വരികൾ തിരികെ നൽകുന്നത്. പാസ്‌വേഡ് ഹാഷുകളും ആന്തരിക ഫീൽഡുകളും ചോരുന്നു. ഓരോ പ്രതികരണത്തിലും എന്ത് ഉൾപ്പെടണമെന്ന് തിരഞ്ഞെടുക്കുക.
- പരിധിയില്ലാത്ത ലിസ്റ്റുകൾ. ഒരു അഭ്യർത്ഥന എല്ലാ റെക്കോർഡുകൾക്കും മുഴുവൻ ആപ്പിനെയും മന്ദഗതിയിലാക്കാം.
- പിശക് സന്ദേശമുള്ള
200 OK. ക്ലയന്റുകൾക്കും മോണിറ്ററിംഗിനും പരാജയം അറിയാൻ കഴിയില്ല. - കുക്കികൾ ഉപയോഗിക്കുന്ന API-യിൽ എല്ലാം അനുവദിക്കുന്ന CORS.
- ഹെൽത്ത് ചെക്കോ ലോഗുകളോ ഇല്ലാത്തത്, അതിനാൽ ഔട്ടേജുകൾ ഉപയോക്താക്കളിൽ നിന്ന് അറിയുന്നു.
വിശാലമായ ലോഞ്ചിന് മുമ്പുള്ള പരിശോധനയ്ക്ക്, AI-നിർമ്മിത ആപ്പുകൾക്കുള്ള സുരക്ഷാ ചെക്ക്‌ലിസ്റ്റ് കാണുക.
Mythex-ൽ REST API നിർമ്മിക്കുന്നത്
നിങ്ങളുടെ ആപ്പിന്റെ ഭാഗമായോ സ്വന്തം സേവനമായോ Mythex-നോട് API ആവശ്യപ്പെടാം. ഡോക്സിലെ REST API ബാക്കെൻഡ് റെസിപ്പിയിൽ ഒരു ആരംഭ പ്രോംപ്റ്റ് ഉണ്ട്: ഫ്രെയിംവർക്കും റൂട്ടുകളും പേര് നൽകുക, വ്യക്തമായ JSON പിശകുകൾ ആവശ്യപ്പെടുക, രഹസ്യങ്ങൾ എൻവയോൺമെന്റ് വേരിയബിളുകളിൽ സൂക്ഷിക്കുക, Dockerfile ഉൾപ്പെടുത്തുക. Node, Python, C#, Java തുടങ്ങിയ കണ്ടെയ്നർ ബാക്കെൻഡുകൾ Dockerfile വഴി പ്രസിദ്ധീകരിക്കുന്നു, Publish-ൽ നിന്ന് Mythex വിന്യാസം കൈകാര്യം ചെയ്യുന്നു (API ബാക്കെൻഡുകൾ). ഒരു പ്രോജക്റ്റിന് വെബ്സൈറ്റും API സെർവറും അടുത്തടുത്ത് പ്രവർത്തിപ്പിക്കാം, പ്രിവ്യൂവിൽ അവയ്ക്കിടയിൽ മാറാം. കീകൾ പ്രോജക്റ്റ് സീക്രട്ടുകളായി സൂക്ഷിക്കുക; API-ക്ക് ഡാറ്റാബേസ് വേണമെങ്കിൽ ചാറ്റിൽ ആവശ്യപ്പെടുക. നിങ്ങളുടെ API-ക്ക് ചുറ്റുമുള്ള ഷെഡ്യൂൾ ചെയ്ത ജോലികൾക്ക്, പശ്ചാത്തല ജോലികൾ എങ്ങനെ പ്രവർത്തിപ്പിക്കാം കാണുക.
ചോദ്യങ്ങൾ
REST API എന്നാൽ എന്ത്?
പ്രോഗ്രാമുകൾക്ക് HTTP വഴി നിങ്ങളുടെ ആപ്പിലെ ഡാറ്റയുമായി പ്രവർത്തിക്കാനുള്ള മാർഗമാണ് REST API. ഓരോ തരം ഡാറ്റയും സ്വന്തം URL ഉള്ള ഒരു റിസോഴ്സ് ആണ്, ഉദാഹരണത്തിന് /orders, സാധാരണ രീതികൾ അതിൽ പ്രവർത്തിക്കുന്നു: വായിക്കാൻ GET, സൃഷ്ടിക്കാൻ POST, മാറ്റാൻ PATCH അല്ലെങ്കിൽ PUT, നീക്കം ചെയ്യാൻ DELETE. ഡാറ്റ സാധാരണയായി JSON ആയി അയക്കുന്നു.
REST API ഏത് ഭാഷയിൽ നിർമ്മിക്കണം?
നിങ്ങൾക്കോ ടീമിനോ പരിപാലിക്കാൻ കഴിയുന്നത് ഉപയോഗിക്കുക. Express അല്ലെങ്കിൽ Fastify ഉള്ള Node.js, FastAPI ഉള്ള Python, C# അല്ലെങ്കിൽ Java ഫ്രെയിംവർക്കുകൾ എല്ലാം നന്നായി പ്രവർത്തിക്കും. റൂട്ടുകൾ, സ്റ്റാറ്റസ് കോഡുകൾ, വാലിഡേഷൻ, ഓതന്റിക്കേഷൻ എന്നിവയുടെ ഡിസൈൻ നിയമങ്ങളാണ് ഭാഷയേക്കാൾ പ്രധാനം.
REST API എങ്ങനെ സുരക്ഷിതമാക്കാം?
പൊതുവല്ലാത്ത ഓരോ റൂട്ടിനും ഓതന്റിക്കേഷൻ വേണം, ഓരോ പ്രത്യേക റെക്കോർഡും വിളിക്കുന്നയാൾക്ക് ആക്സസ് ചെയ്യാമോ എന്ന് സെർവറിൽ പരിശോധിക്കുക, എല്ലാ ഇൻപുട്ടും വാലിഡേറ്റ് ചെയ്യുക, HTTPS ഉപയോഗിക്കുക, അഭ്യർത്ഥനകൾക്ക് റേറ്റ് ലിമിറ്റ് വെക്കുക, രഹസ്യങ്ങൾ എൻവയോൺമെന്റ് വേരിയബിളുകളിൽ സൂക്ഷിക്കുക. ക്ലയന്റ് അയക്കുന്ന ID-കളെയോ റോളുകളെയോ ഒരിക്കലും വിശ്വസിക്കരുത്.
REST API-ക്ക് പ്രത്യേക ബാക്കെൻഡ് വേണോ?
എല്ലായ്പ്പോഴും വേണ്ട. Next.js പോലുള്ള ഫ്രെയിംവർക്കുകൾക്ക് പേജുകൾക്കൊപ്പം API റൂട്ടുകളും നൽകാം. വെബ്, മൊബൈൽ, പങ്കാളികൾ പോലുള്ള പല ക്ലയന്റുകൾ ഉപയോഗിക്കുമ്പോഴോ അതിന് സ്വന്തം ഭാഷയോ സ്കെയിലിംഗോ വേണമ്പോഴോ പ്രത്യേക API സേവനം അർത്ഥവത്താണ്.