REST (Representational State Transfer) என்பது Roy Fielding-ஆல் வரையறுக்கப்பட்ட, networked applications-க்கான ஒரு architectural style. இது ஒரு protocol அல்லது standard அல்ல — இது தொடரும்போது ஒரு API-ஐ scalable, cacheable, மற்றும் எளிதில் பரிணமிக்கக்கூடியதாக்கும் constraints தொகுப்பு. ஒரு "RESTful" API எல்லாவற்றையும் URIs-ஆல் அடையாளம் காணப்படும் resources (users, orders, products) ஆக model செய்து, அவற்றை 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 action; JSON representation. அந்த சேர்க்கை — path-இல் nouns, HTTP methods ஆக verbs — REST-இன் இதயம்.
REST என்பது web APIs-க்கான ஆதிக்க style, எனவே அதை எழுத்துக்கூட்ட முடியும் என்பது மட்டுமல்லாமல் அது ஏன் வேலை செய்கிறது என்பதை நீங்கள் புரிந்துகொள்கிறீர்களா என்று சரிபார்க்க interviewers இந்தக் கேள்வியைப் பயன்படுத்துகிறார்கள். நடைமுறையில் மிக முக்கியமான இரண்டு constraints statelessness (ஒவ்வொரு request-ம் சுய-உள்ளடக்கமானது, எனவே எத்தனை servers-ஐயும் ஒரு load balancer-க்குப் பின்னால் வைத்து sticky sessions இல்லாமல் horizontally scale செய்யலாம்) மற்றும் uniform interface (கணிக்கக்கூடிய, resource-oriented URLs கூடிய standard HTTP methods மற்றும் status codes, அதாவது clients-க்கு endpoint-க்கு endpoint custom logic தேவையில்லை). ஒரு வலுவான பதில் constraints-ஐ உறுதியான நன்மைகளுடன் இணைக்கிறது — statelessness scaling-ஐ இயலச்செய்கிறது, cacheability load-ஐக் குறைக்கிறது, layered system CDNs மற்றும் gateways-ஐச் செருக அனுமதிக்கிறது — மேலும் பெரும்பாலான "REST" APIs முழுமையாக RESTful அல்ல, நடைமுறையானவை (சிலவே HATEOAS-ஐ செயல்படுத்துகின்றன) என்பதைக் குறிக்கிறது. இந்த constraints-ஐப் புரிந்துகொள்வதே status codes தேர்ந்தெடுப்பது முதல் versioning வரை மற்ற ஒவ்வொரு REST design முடிவுக்கும் அடித்தளம்.
விரிவான பதில்களுடன் கூடிய IT நேர்காணல் கேள்விகளின் நூலகம் — Junior முதல் Senior வரை.
நன்கொடை