REST API કેવી રીતે બનાવવી: ડિઝાઇન, સુરક્ષા અને ડિપ્લોયમેન્ટ
REST API બનાવવા માટે, તમારી એપ જે રિસોર્સ સંભાળે છે (વપરાશકર્તાઓ, ઓર્ડર, બુકિંગ) તેની યાદી બનાવો, દરેકને /orders અને /orders/{id} જેવું URL આપો, અને ક્રિયાઓ માટે HTTP મેથડ વાપરો: વાંચવા માટે GET, બનાવવા માટે POST, અપડેટ માટે PATCH, કાઢી નાખવા માટે DELETE. અર્થપૂર્ણ સ્ટેટસ કોડ સાથે JSON પરત કરો, દરેક ઇનપુટ વેલિડેટ કરો, સર્વર પર ઓથેન્ટિકેશન અને પ્રતિ-રેકોર્ડ પરવાનગી તપાસ ફરજિયાત રાખો, અને યાદીઓને પેજમાં વહેંચો. પછી એન્ડપોઇન્ટ દસ્તાવેજીકૃત કરો અને API ને HTTPS પાછળ ડિપ્લોય કરો.
આ માર્ગદર્શિકા ડિઝાઇનના નિર્ણયો, કામ કરતા રૂટનો એક સેટ, 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 |
આ CRUD (બનાવો, વાંચો, અપડેટ કરો, કાઢી નાખો) સાથે મેળ ખાય છે; જુઓ CRUD શું છે. અનુસરવા લાયક નિયમો:
- URL માં બહુવચન સંજ્ઞાઓ, ક્રિયાપદ નહીં:
/bookings,/getBookingsનહીં. - માલિકી સ્પષ્ટ કરવા માટે માત્ર એક સ્તર નેસ્ટ કરો:
/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 સ્પેક, જેમાંથી ટૂલ્સ ઇન્ટરેક્ટિવ ડોક્સ અને ક્લાયન્ટ કોડ બનાવી શકે |
પગલાવાર
- ઉપર મુજબ રિસોર્સ અને રૂટની યાદી બનાવો, કોણ દરેકને કૉલ કરી શકે તે સહિત.
- તમને જરૂરી ફીલ્ડ અને સંબંધો સાથે તમારા ડેટાબેઝમાં ડેટાનું મોડેલ બનાવો.
- પહેલા વાંચવાના રૂટ બનાવો, પછી બનાવવા, અપડેટ અને કાઢી નાખવાના.
- દરેક રાઇટ પર સ્કીમા લાઇબ્રેરી વડે ઇનપુટ વેલિડેટ કરો: ફરજિયાત ફીલ્ડ, પ્રકારો, લંબાઈ, માન્ય મૂલ્યો. અજાણ્યા ફીલ્ડ નકારો.
- ઓથેન્ટિકેશન ઉમેરો, પછી પ્રતિ-રેકોર્ડ ઓથોરાઇઝેશન:
/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, ID વડે વપરાશકર્તા B નો રેકોર્ડ માંગે ત્યારે 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 દ્વારા પ્રકાશિત થાય છે, અને Mythex Publish માંથી ડિપ્લોયનું સંચાલન કરે છે (API બેકએન્ડ). એક પ્રોજેક્ટ વેબસાઇટ અને API સર્વર સાથે ચલાવી શકે છે, અને પ્રીવ્યૂમાં બંને વચ્ચે સ્વિચ કરી શકાય છે. સ્ટોર કીઓ પ્રોજેક્ટ સિક્રેટ્સ તરીકે રાખો, અને જો API ને ડેટાબેઝ જોઈએ, તો ચેટમાં માંગો. તમારી API સાથે જોડાયેલા શેડ્યૂલ્ડ કામ માટે, જુઓ બેકગ્રાઉન્ડ જોબ્સ કેવી રીતે ચલાવવી.
પ્રશ્નો
REST API શું છે?
REST API એ પ્રોગ્રામો માટે HTTP પર તમારી એપના ડેટા સાથે કામ કરવાનો એક રસ્તો છે. ડેટાનો દરેક પ્રકાર તેના પોતાના 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 સેવા યોગ્ય છે.