REST (Representational State Transfer) networked ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ ਇੱਕ architectural style ਹੈ, ਜੋ Roy Fielding ਦੁਆਰਾ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤੀ ਗਈ। ਇਹ ਕੋਈ protocol ਜਾਂ standard ਨਹੀਂ — ਇਹ constraints ਦਾ ਇੱਕ ਸਮੂਹ ਹੈ ਜੋ, ਪਾਲਣ ਕਰਨ 'ਤੇ, ਇੱਕ API ਨੂੰ scalable, cacheable, ਅਤੇ ਵਿਕਸਤ ਕਰਨ ਵਿੱਚ ਆਸਾਨ ਬਣਾਉਂਦੇ ਹਨ। ਇੱਕ "RESTful" API ਹਰ ਚੀਜ਼ ਨੂੰ resources (users, orders, products) ਵਜੋਂ ਮਾਡਲ ਕਰਦੀ ਹੈ ਜੋ URIs ਦੁਆਰਾ ਪਛਾਣੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਮਿਆਰੀ 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 ਹੈ, ਇਸ ਲਈ ਇੰਟਰਵਿਊ ਲੈਣ ਵਾਲੇ ਇਹ ਸਵਾਲ ਇਹ ਜਾਂਚਣ ਲਈ ਵਰਤਦੇ ਹਨ ਕਿ ਤੁਸੀਂ ਸਮਝਦੇ ਹੋ ਕਿ ਇਹ ਕਿਉਂ ਕੰਮ ਕਰਦੀ ਹੈ, ਨਾ ਕਿ ਸਿਰਫ਼ ਇਸਦਾ ਨਾਮ ਲੈ ਸਕਦੇ ਹੋ। ਅਮਲ ਵਿੱਚ ਸਭ ਤੋਂ ਵੱਧ ਮਾਇਨੇ ਰੱਖਣ ਵਾਲੀਆਂ ਦੋ constraints ਹਨ statelessness (ਹਰ request ਸਵੈ-ਨਿਹਿਤ ਹੈ, ਇਸ ਲਈ ਤੁਸੀਂ ਇੱਕ load balancer ਪਿੱਛੇ ਜਿੰਨੇ ਚਾਹੋ servers ਰੱਖ ਸਕਦੇ ਹੋ ਅਤੇ sticky sessions ਬਿਨਾਂ horizontally scale ਕਰ ਸਕਦੇ ਹੋ) ਅਤੇ uniform interface (ਅਨੁਮਾਨਯੋਗ, resource-ਅਧਾਰਿਤ URLs ਅਤੇ ਮਿਆਰੀ HTTP methods ਤੇ status codes, ਜਿਸ ਦਾ ਮਤਲਬ ਹੈ ਕਿ clients ਨੂੰ ਹਰ endpoint ਲਈ custom logic ਦੀ ਲੋੜ ਨਹੀਂ)। ਇੱਕ ਮਜ਼ਬੂਤ ਜਵਾਬ constraints ਨੂੰ ਠੋਸ ਲਾਭਾਂ ਨਾਲ ਜੋੜਦਾ ਹੈ — statelessness scaling ਨੂੰ ਸੰਭਵ ਬਣਾਉਂਦੀ ਹੈ, cacheability ਲੋਡ ਘਟਾਉਂਦੀ ਹੈ, layered system ਤੁਹਾਨੂੰ CDNs ਅਤੇ gateways ਪਾਉਣ ਦਿੰਦਾ ਹੈ — ਅਤੇ ਇਹ ਨੋਟ ਕਰਦਾ ਹੈ ਕਿ ਬਹੁਤੇ "REST" APIs ਪੂਰੀ ਤਰ੍ਹਾਂ RESTful ਹੋਣ ਦੀ ਬਜਾਏ ਵਿਹਾਰਕ ਹਨ (ਬਹੁਤ ਘੱਟ HATEOAS ਲਾਗੂ ਕਰਦੇ ਹਨ)। ਇਹਨਾਂ constraints ਨੂੰ ਸਮਝਣਾ ਹਰ ਦੂਜੇ REST design ਫ਼ੈਸਲੇ ਦੀ ਨੀਂਹ ਹੈ, status codes ਚੁਣਨ ਤੋਂ ਲੈ ਕੇ versioning ਤੱਕ।
ਵਿਸਤ੍ਰਿਤ ਜਵਾਬਾਂ ਨਾਲ IT ਇੰਟਰਵਿਊ ਸਵਾਲਾਂ ਦੀ ਇੱਕ ਲਾਇਬ੍ਰੇਰੀ — ਜੂਨੀਅਰ ਤੋਂ ਸੀਨੀਅਰ ਤੱਕ।
ਦਾਨ ਕਰੋ