Theory
Methods અને URLs સાથે મળીને
FestConnect ના backend એ front end ને events ની યાદી વાંચવા દેવી પડે, registration ઉમેરવા દેવું પડે, વિગત સુધારવા દેવી પડે અને entry કાઢી નાખવા દેવી પડે. આમાંનું દરેક એટલે એક route: HTTP method (કઈ ક્રિયા) અને URL path (કયું resource) ની જોડી.
ચાર મુખ્ય methods ચાર પાયાની data ક્રિયાઓ સાથે સરસ રીતે બંધ બેસે છે. આ પાઠ બતાવે છે કે Express GET, POST, PUT અને DELETE માટે routes કઈ રીતે વ્યાખ્યાયિત કરે છે, handler request માંથી parameters કઈ રીતે વાંચે છે અને જવાબ કઈ રીતે મોકલે છે, તથા logic ને controllers માં કઈ રીતે વ્યવસ્થિત રખાય છે. REST API બનાવવાનું આ જ હાર્દ છે.
At a glance
| Method | ક્રિયા | FestConnect દાખલો |
|---|---|---|
| GET | Data વાંચવો | GET /api/events, events ની યાદી આપે |
| POST | નવો data બનાવવો | POST /api/registrations, registration ઉમેરે |
| PUT | હાલનો data સુધારવો | PUT /api/events/5, event 5 માં ફેરફાર કરે |
| DELETE | Data કાઢી નાખવો | DELETE /api/events/5, event 5 કાઢી નાખે |
Practical
ચારેય methods માટે routes વ્યાખ્યાયિત કરવા
app.get('/api/events', (req, res) => {
res.json(events); // read: યાદી મોકલો
});
app.post('/api/events', (req, res) => {
const newEvent = req.body; // create: data request body માં હોય છે
events.push(newEvent);
res.status(201).json(newEvent); // 201 = Created
});
app.put('/api/events/:id', (req, res) => { /* event :id ને update કરો */ });
app.delete('/api/events/:id', (req, res) => { /* event :id ને દૂર કરો */ });This example runs in Gri-Learn on the web, where you can edit it and see the output.
Theory
Route parameters અને query parameters
Requests બે સામાન્ય URL સ્વરૂપોમાં data સાથે લાવે છે.
Route parameters એ path ના નામવાળા ભાગ છે, જે colon સાથે લખાય છે: /api/events/:id માં :id એ ખાલી જગ્યા છે. /api/events/5 પર request આવે ત્યારે Express તમને req.params.id આપે છે જેની કિંમત '5' હોય છે. ચોક્કસ resource ઓળખવા માટે આ વાપરો.
Query parameters URL માં ? પછી key અને કિંમતની જોડી તરીકે આવે છે: /api/events?category=tech. Express એમને req.query માંથી વાંચે છે, એટલે req.query.category એ 'tech' થાય. Filters, searches અને વિકલ્પો માટે આ વાપરો. એટલે route params કહે છે કે કયું resource જોઈએ છે; query params સ્પષ્ટ કરે છે કે એ કઈ રીતે જોઈએ છે.
Practical
Route અને query parameters વાંચવા
// Route parameter: કયો event? (/api/events/5)
app.get('/api/events/:id', (req, res) => {
const id = req.params.id; // '5'
res.json(findEvent(id));
});
// Query parameter: યાદી filter કરો (/api/events?category=tech)
app.get('/api/events', (req, res) => {
const category = req.query.category; // 'tech' (અથવા undefined)
res.json(category ? filterByCategory(category) : events);
});This example runs in Gri-Learn on the web, where you can edit it and see the output.
Quiz
Front end ને કોઈ ચોક્કસ event એના id પ્રમાણે DELETE કરવા દેવું હોય, તો REST ના રિવાજ પ્રમાણે કયું HTTP method અને કયો path આકાર બંધ બેસે?
- GET /api/events, કારણ કે GET બધું જ કરી લે છે
- DELETE /api/events/:id, એટલે કે DELETE method અને id માટે route parameter વાપરીને
- POST /api/deleteEvent, કારણ કે ક્રિયાઓ માટે POST હોય છે
- PUT /api/events, કારણ કે PUT data કાઢી નાખે છે
Show the answer
DELETE /api/events/:id, એટલે કે DELETE method અને id માટે route parameter વાપરીને
REST માં resource કાઢી નાખવા માટે DELETE method વપરાય છે, અને કયું resource એ route parameter ઓળખાવે છે, એટલે DELETE /api/events/:id (દા.ત. /api/events/5) એ રિવાજી આકાર છે. વિકલ્પ A માં GET નો દુરુપયોગ થાય છે, જે data વાંચવા માટે છે, કાઢી નાખવા માટે નહીં (અને GET થી data બદલવો એ REST તોડે છે તથા જોખમી છે). વિકલ્પ C ટેક્નિકલી ચાલે ખરો, પણ REST ના રિવાજ અવગણે છે: ક્રિયા HTTP method માં (DELETE) હોવી જોઈએ, POST સાથે /deleteEvent તરીકે URL માં ભેળવેલી નહીં. વિકલ્પ D ખોટો છે: PUT હાલના resource ને સુધારવા માટે છે, કાઢી નાખવા માટે નહીં. Method ને ક્રિયા સાથે મેળવો: GET વાંચે, POST બનાવે, PUT સુધારે, DELETE કાઢે, અને ચોક્કસ વસ્તુ તાકવા માટે route parameter વાપરો.
Think first
ક્રિયા URL ને બદલે HTTP method પાસે કેમ રખાવવી?
તમે URL ને /getEvents અને /deleteEvent જેવાં નામ પણ આપી શકો. તો REST ક્રિયાને method માં કેમ મૂકે છે અને URL ને resources પૂરતાં કેમ રાખે છે? વિચારીને પછી tap કરો.
Show the answer
કારણ કે RESOURCE (URL) ને ACTION (HTTP method) થી અલગ રાખવાથી API સ્વચ્છ, અનુમાનજોગ અને પ્રમાણભૂત બને છે, જ્યારે URL માં ક્રિયાપદો ભેળવવાથી અસંગત નામોનો ફેલાવો થાય છે. REST માં URL વસ્તુને નામ આપે છે, /api/events એટલે 'events', /api/events/5 એટલે 'event 5', અને method કહે છે કે એ વસ્તુ સાથે તમારે શું કરવું છે: એને GET કરવી, નવી POST કરવી, એને PUT (update) કરવી, કે DELETE કરવી. એનો અર્થ એ કે એક જ URL જુદાં જુદાં methods દ્વારા અનેક ક્રિયાઓ સંભાળે છે, અને કોઈ પણ developer API નો અંદાજ બાંધી શકે છે: event 5 સુધારવો હોય તો એ જાણે છે કે એ PUT /api/events/5 છે, કોઈ ખાસ ક્રિયાપદવાળા URL ની યાદી જોયા વગર. બીજી બાજુ /getEvents, /addEvent, /deleteEvent, /updateEvent વાળી રીત ઝડપથી અસંગત નામોનું જંગલ બની જાય છે (/removeEvent કે /deleteEvent? /events/new કે /addEvent?), અને એ HTTP methods ને વેડફે છે જે આ જ ક્રિયાઓ દર્શાવવા માટે તો પહેલેથી છે. Methods વાપરવાથી web નું આખું માળખું પણ તમને મદદ કરે છે: GET સલામત અને cache કરી શકાય એવું ગણાય છે, DELETE અને PUT data બદલે છે એમ સમજાય છે, એટલે browsers, proxies અને tools સમજદારીથી વર્તે છે. સુરક્ષા વિશે વિચારવામાં પણ એ મદદ કરે છે (તમે GET થી data ક્યારેય બદલતા નથી). એટલે REST ની આ શિસ્ત, એટલે કે URL માં નામ અને method માં ક્રિયાપદ, એ કોઈ પંડિતાઈ નથી; એ એવાં APIs બનાવે છે જે સુસંગત હોય, શોધી શકાય એવાં હોય અને web સાથે સારી રીતે ભળે. Path માં resources, method માં ક્રિયાઓ.
Summary
Key takeaways
- Route એ HTTP method ને URL path અને handler function સાથે જોડે છે.
- ચાર મુખ્ય methods CRUD સાથે બંધ બેસે છે: GET વાંચે, POST બનાવે, PUT સુધારે, DELETE કાઢી નાખે.
- Express એમને app.get/post/put/delete(path, handler) થી વ્યાખ્યાયિત કરે છે; handler ને (req, res) મળે છે.
- જવાબ res.json() કે res.send() થી મોકલો, અને status res.status() થી ગોઠવો (દા.ત. 201 Created).
- Route parameters path ના ભાગને નામ આપે છે (/events/:id, req.params.id દ્વારા વંચાય) જેથી resource ઓળખાય.
- Query parameters URL માં ? પછી આવે છે (/events?category=tech, req.query.category દ્વારા વંચાય), filters અને વિકલ્પો માટે.
- યાદ રાખવાની કડી: URL માં resource, method માં ક્રિયા; path માં :id, query માં filters.