REST (Representational State Transfer) એ networked applications માટેની એક architectural style છે, જે Roy Fielding દ્વારા વ્યાખ્યાયિત છે. તે protocol કે standard નથી — તે constraints નો સમૂહ છે જે, અનુસરવામાં આવે ત્યારે, API ને scalable, cacheable, અને વિકસાવવામાં સરળ બનાવે છે. "RESTful" API બધું જ URIs દ્વારા ઓળખાયેલા resources (users, orders, products) તરીકે મૉડેલ કરે છે, અને standard HTTP methods વાપરીને તેમને હેરફેર કરે છે.
GET /users/42 HTTP/1.1
Host: api.example.com
Accept: application/json
HTTP/1.1 200 OK
Content-Type: application/json
{ "id": 42, "name": "Ann", "email": "[email protected]" }
URI /users/42 resource ને નામ આપે છે; GET એ ક્રિયા છે; JSON એ representation છે. એ સંયોજન — path માં nouns, HTTP methods તરીકે verbs — એ REST નું હૃદય છે.
REST એ web APIs માટે પ્રબળ style છે, તેથી interviewers આ પ્રશ્નનો ઉપયોગ એ તપાસવા કરે છે કે તમે શા માટે તે કામ કરે છે તે સમજો છો, ફક્ત તેની જોડણી કરી શકો છો એટલું નહીં. વ્યવહારમાં સૌથી મહત્વની બે constraints છે statelessness (દરેક request સ્વ-સમાયેલ છે, તેથી તમે load balancer પાછળ ગમે તેટલા servers મૂકી શકો અને sticky sessions વગર horizontally scale કરી શકો) અને uniform interface (અનુમાનિત, resource-oriented URLs વત્તા standard HTTP methods અને status codes, જેનો અર્થ છે clients ને દર endpoint માટે custom logic ની જરૂર નથી). મજબૂત જવાબ constraints ને નક્કર ફાયદાઓ સાથે જોડે છે — statelessness scaling ને શક્ય બનાવે છે, cacheability load ઘટાડે છે, layered system તમને CDNs અને gateways દાખલ કરવા દે છે — અને નોંધે છે કે મોટા ભાગની "REST" APIs સંપૂર્ણ RESTful ને બદલે વ્યવહારુ છે (થોડી જ HATEOAS અમલમાં મૂકે છે). આ constraints સમજવી એ status codes પસંદ કરવાથી લઈને versioning સુધીના દરેક બીજા REST design નિર્ણય માટેનો પાયો છે.
વિગતવાર જવાબો સાથે IT ઇન્ટરવ્યૂ પ્રશ્નોની લાઇબ્રેરી — જુનિયરથી સિનિયર સુધી.
દાન કરો