Theory
મોટાભાગની APIs follow કરતી style
તમારું app web serviceને call કરે ત્યારે તે service ઘણીવાર એક ખાસ style follow કરે છે: REST. REST સમજવાથી તમે મળતી ઘણી APIsને કેવી રીતે વાપરવી તે predict કરી શકો છો, કારણ કે તેમાં common conventions હોય છે.
Express backend બનાવતી વખતે તમે RESTને server sideથી જોયું હતું; હવે તમે તેને consumer તરીકે જુઓ છો, એટલે app APIને call કરે છે. આ lesson RESTના core ideas (resources, methods, statelessness અને JSON) સમજાવે છે, જેથી API documentation વાંચીને યોગ્ય call કરવી સરળ બને. REST web APIsની common language જેવી છે.
At a glance
| Principle | What it means |
|---|---|
| Resources as URLs | દરેક વસ્તુનો URL હોય છે: /events, /events/5 |
| Methods as actions | GET વાંચે છે, POST બનાવે છે, PUT update કરે છે, DELETE દૂર કરે છે |
| Stateless | દરેક requestમાં જરૂરી બધું હોય છે; server requests વચ્ચે client session રાખતું નથી |
| JSON data | Requests અને responses સામાન્ય રીતે JSON exchange કરે છે |
| Status codes | Response outcome બતાવે છે: 200 OK, 404 Not Found અને બીજા codes |
Theory
Resources, methods અને JSON
RESTમાં URL resource એટલે કોઈ વસ્તુનું નામ આપે છે: /events eventsનું collection છે અને /events/5 event 5 છે. HTTP method તે resource સાથે શું કરવું તે કહે છે: GET read માટે, POST create માટે, PUT update માટે અને DELETE remove માટે. આ એ જ idea છે: nouns URLમાં અને verbs methodમાં.
Data બંને તરફ JSON તરીકે જાય છે અને દરેક responseમાં status code હોય છે, જેમ કે success માટે 200 અને resource ન મળે ત્યારે 404. એટલે FestConnectના events મેળવવા app /events endpoint પર GET મોકલે છે અને પાછા મળેલા JSON listને parse કરે છે. Server કોઈ પણ languageમાં લખાયેલો હોય, RESTનું pattern predictable અને uniform રહે છે.
Formula
Stateless એટલે દરેક request પોતે complete
RESTનું defining principle statelessness છે: દરેક requestમાં serverને તેને handle કરવા માટેનું બધું જરૂરી information હોવું જોઈએ. Server requests વચ્ચે app વિશે કંઈ યાદ રાખતું નથી અને server-side session requestને એકબીજા સાથે જોડતી નથી.
જો requestને user કોણ છે તે જાણવું હોય, તો દરેક વખતે auth token મોકલવો પડે છે; server છેલ્લી callથી તમને 'યાદ' રાખતું નથી. આ REST APIsને simple અને scalable બનાવે છે, કારણ કે કોઈ પણ server કોઈ પણ request handle કરી શકે છે. App માટે rule છે: દરેક requestને જે જોઈએ તે તેમાં include કરો; server અગાઉની request યાદ રાખે છે એવું માનશો નહીં.
Quiz
`/events` endpoint પરથી eventsની list read કરવા app કઈ HTTP method વાપરે?
- POST, કારણ કે તે powerful છે
- GET, કારણ કે RESTમાં GET resource read અથવા retrieve કરે છે
- DELETE, કારણ કે તે data fetch કરે છે
- કોઈ method નથી; browserમાં URL ખોલી દો
Show the answer
GET, કારણ કે RESTમાં GET resource read અથવા retrieve કરે છે
RESTમાં GET resource read અથવા retrieve કરવા માટેની method છે, તેથી events list મેળવવા /events પર GET request મોકલાય છે. Option A ખોટું છે: POST નવી resource CREATE કરવા માટે છે, જેમ કે નવો event add કરવો, read કરવા માટે નહીં. Option C ખોટું છે: DELETE resource remove કરે છે, read કરવાનો વિરોધી action છે. Option D mechanismને સમજી શકતું નથી: browserમાં URL ખોલવાથી પણ GET જ થાય છે, પરંતુ app library, જેમ કે Volley, વડે GET programmatically મોકલીને JSON મેળવે છે; styled webpage નહીં. Method યાદ રાખો: GET read, POST create, PUT update, DELETE remove.
Think first
Statelessness API scaling માટે સારું કેમ છે?
REST servers requests વચ્ચે app વિશે memory રાખતા નથી. આ limitationને બદલે strength કેમ છે? પછી tap.
Show the answer
કારણ કે દરેક request SELF-CONTAINED હોય અને server per-client session store ન કરે, તેથી ANY server ANY request handle કરી શકે છે. આ systemને scale કરવું અને reliable રાખવું સરળ બનાવે છે.
માનો load balancerની પાછળ અનેક identical servers API ચલાવે છે. જો serversને દરેક client વિશે session યાદ રાખવી પડે, તો appની આગળની requests એ જ server પર જવી જોઈએ જ્યાં session છે, અથવા session state બધા servers વચ્ચે share અને synchronize કરવી પડશે. બંને approaches complicated અને fragile છે. એ server crash થાય તો session પણ ગુમાઈ શકે છે.
STATELESS RESTમાં દરેક request serverને જરૂરી બધું, જેમાં token દ્વારા user identity પણ સામેલ છે, લઈને આવે છે. તેથી કયો server request handle કરે છે તે matter કરતું નથી. Requests અનેક machines પર freely distribute કરી શકાય છે અને load વધે ત્યારે વધુ servers add કરી શકાય છે, session affinityની ચિંતા વગર. Server failureથી client state ગુમાતી નથી, કારણ કે server પાસે stored client session જ નથી.
Cost એટલો છે કે દરેક requestમાં auth token જેવી કેટલીક information ફરી મોકલવી પડે છે. Scalability અને reliabilityના મોટા લાભ સામે આ નાનો overhead છે. Stored session ન હોવાને કારણે કોઈ પણ server કોઈ પણ request serve કરી શકે છે, અને મોટા systems માટે આ ખૂબ ઉપયોગી છે.
Summary
Key takeaways
- REST (Representational State Transfer) web APIs માટેનું common architectural style છે.
- Resources URLsથી ઓળખાય છે, જેમ કે
/eventsઅને/events/5; HTTP methods actions બતાવે છે. - GET read, POST create, PUT update અને DELETE remove માટે વપરાય છે.
- REST stateless છે: દરેક requestમાં જરૂરી information હોય છે અને server client session store કરતું નથી.
- Data સામાન્ય રીતે JSONમાં exchange થાય છે અને responses status codes આપે છે, જેમ કે 200 OK અને 404 Not Found.
- Consumer sideથી events મેળવવા
/eventsપર GET મોકલીને મળેલું JSON parse કરો. - Memory hook: resources URLsમાં, actions methodsમાં, requests stateless, data JSONમાં અને outcome status codesમાં.