الـ REST (Representational State Transfer) هو أسلوب معماري (architectural style) للتطبيقات الشبكية، عرّفه Roy Fielding. وهو ليس بروتوكولًا ولا معيارًا — بل مجموعة قيود (constraints) تجعل الـ API، حين تُتَّبع، قابلًا للتوسّع والـ caching وسهل التطوير. تُنمذِج الـ API الـ "RESTful" كل شيء كـ موارد (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 يسمّي المورد؛ وGET هو الفعل؛ وJSON هو التمثيل. تلك التركيبة — أسماء في المسار، أفعال كـ HTTP methods — هي جوهر REST.
REST هو الأسلوب المهيمن لواجهات الويب البرمجية، لذا يستخدم المُقابِلون هذا السؤال للتحقق من أنك تفهم لماذا ينجح، لا مجرّد أنك تحفظ اسمه. القيدان الأهم عمليًّا هما statelessness (كل طلب مكتفٍ ذاتيًّا، فتستطيع وضع أي عدد من الخوادم خلف موازِن حمل والتوسّع أفقيًّا دون sticky sessions) وuniform interface (عناوين URL متوقّعة موجّهة بالموارد إضافةً إلى HTTP methods وstatus codes قياسية، ما يعني ألّا يحتاج العملاء إلى منطق خاص بكل endpoint). الإجابة القوية تربط القيود بمنافع ملموسة — الـ statelessness يتيح التوسّع، والـ cacheability تقلّل الحمل، والـ layered system يتيح إدراج CDNs وgateways — وتلاحظ أن معظم واجهات "REST" عملية وليست RESTful بالكامل (قليلة تُطبِّق HATEOAS). فهم هذه القيود هو الأساس لكل قرار تصميم REST آخر، من اختيار status codes إلى الـ versioning.
مكتبة من أسئلة مقابلات تقنية المعلومات مع إجابات مفصّلة — من المبتدئ إلى المتقدم.
تبرع