ينبغي أن يُقرأ URI المورد كـ مسار قائم على أسماء نحو "شيء"، لا كفعل. فالـ HTTP method يوفّر الفعل بالفعل، لذا لا يحتاج الـ URI إلا إلى تعريف المورد بوضوح واتّساق.
ينبغي أن يُقرأ URI المورد كـ مسار قائم على أسماء نحو "شيء"، لا كفعل. فالـ HTTP method يوفّر الفعل بالفعل، لذا لا يحتاج الـ URI إلا إلى تعريف المورد بوضوح واتّساق.
GET /users/42 — وليس GET /getUser?id=42. الـ method (GET) هو الفعل./users هي المجموعة؛ و/users/42 عضو واحد. البقاء على الجمع في كل مكان يبقيه متوقّعًا./users/42/orders = "الطلبات التابعة للمستخدم 42".kebab-case بأحرف صغيرة. /blog-posts، وليس /blogPosts أو /Blog_Posts./users?role=admin&sort=-created_at./users collection of users
/users/42 a single user
/users/42/orders orders belonging to user 42 (sub-collection)
/users/42/orders/1001 a specific order of that user
/orders/1001 same order, addressable at top level too
GET /users/42/orders?status=shipped&sort=-created_at&page=2 HTTP/1.1
Accept: application/json
تجنّب التداخل العميق أكثر من مستوى أو مستويين — /users/42/orders/1001/items/5/reviews يصير هشًّا. وبمجرّد أن يصبح للطلب مُعرّف خاص، فضّل /orders/1001. وبالنسبة للأفعال التي لا تناسب CRUD (مثل "إرسال بريد")، يكون مورد فرعي بأسلوب controller مقبولًا: POST /users/42/verify-email.
التسمية المتّسقة هي ما يجعل الـ API يبدو بديهيًّا — فالمطوّر الذي رأى /users و/users/42 يستطيع تخمين /products و/products/99 بشكل صحيح دون قراءة التوثيق. يستخدم المُقابِلون هذا لقياس ما إذا كنت تفكّر بـ الموارد (عقلية REST) لا بـ استدعاءات RPC (/doThisThing). أكثر الأنماط المضادة شيوعًا — أفعال في المسار، وجمع/إفراد غير متّسق، وعناوين URL عميقة التداخل — تجعل الـ API أصعب تعلّمًا وصيانةً، وتشير إلى مطوّر لم يستوعب قيد uniform-interface في REST. كما أن تصميم URI الجيّد يبقي الاهتمامات منفصلة: الهوية في المسار، والترشيح والتصفّح في الـ query string، ما يبقي الـ caching والتوجيه (routing) نظيفَين.
مكتبة من أسئلة مقابلات تقنية المعلومات مع إجابات مفصّلة — من المبتدئ إلى المتقدم.
تبرع