نقطة نهاية API هي نقطة اتصال بين برنامجين. واجهات برمجة التطبيقات لها نقاط نهاية لكل مورد. تحدد نقاط النهاية الموقع الدقيق للمورد على الخادم.
عندما يطلب تطبيق العميل معلومات من الخادم ، فإنه يمر عبر API. والذي يصل بعد ذلك إلى الطلب ويعالج استجابة من الخادم. تقوم واجهة برمجة التطبيقات بعد ذلك بنقل المعلومات المطلوبة من نقطة النهاية إلى التطبيق.
واجهة برمجة التطبيقات الخاصة بك فعالة إذا كان يمكنها التواصل بشكل فعال عبر نقاط النهاية الخاصة بها. يسهل على المستخدمين الوصول إلى الموارد وتحسين تجربة المستخدم.
كيف تعمل نقطة نهاية API؟
تتواصل الأنظمة المتكاملة من خلال واجهات برمجة التطبيقات. يرسل نظام واحد طلبًا إلى API ، باستخدام تنسيق مثل SOAP أو REST. يتلقى الخادم الطلبات وينقل الاستجابة مرة أخرى إلى واجهة برمجة التطبيقات. موقع هذا المورد المطلوب هو نقطة النهاية.
قبل أن تعالج نقطة النهاية طلبًا ، يجب على العميل توفير عنوان URL ورؤوس ونص. تحتوي الرؤوس على بيانات وصفية حول طلب وبيانات تفاصيل الجسم المرسلة إلى الخادم. يمكن للخادم أيضًا الاتصال بقاعدة بيانات
طرق API يمكن الوصول.تعمل نقاط نهاية API عادةً مع طرق HTTP مثل GET أو DELETE أو PATCH أو POST. تحدد الطرق كيفية استخدام نقطة النهاية. عندما يرسل العميل طلبًا ، فإنه يحتاج إلى صياغته لتضمين طريقة الطلب بالإضافة إلى عنوان URL ، على سبيل المثال:
يحصل https://example.com/books/authorsالتسمية صعبة ، سواء كانت نقاط نهاية لواجهة برمجة التطبيقات ، الأجهزة المتصلة بالشبكة، أو الدوال والمتغيرات. يجب أن تتعرف على بعض أفضل الممارسات التي يمكنك استخدامها للتأكد من أن نقاط نهاية API الخاصة بك هي أحد الأصول.
1. استخدم شرطة مائلة للأمام
استخدم دائمًا الشرطات المائلة للأمام لفصل موارد URI. تساعد الخطوط المائلة أيضًا في إظهار التسلسل الهرمي للموارد. وفيما يلي مثال على ذلك:
https://example.com/books/authors2. استخدم الأسماء وليس الأفعال
يجب عليك فقط استخدام الأسماء لتسمية مورد. تصف الأسماء ماهية المصدر بدلاً من الفعل الذي يصف ما يفعله المورد. فيما يلي مثال على طريقة جيدة وسيئة لتسمية نقاط نهاية API.
التسمية الجيدة:
https://example.com/api/getBooksتسمية سيئة:
http://example.com/api/books3. استخدم الأسماء الجمع ، وليس المفرد
يجب عليك دائمًا تسمية نقاط نهاية API الخاصة بك بأسماء الجمع. يشير هذا إلى المستخدم إلى وجود أكثر من مورد واحد على الخادم. قد يؤدي استخدام اسم مفرد إلى إرباك المستخدم ودفعه إلى الاعتقاد بوجود مورد واحد فقط.
التسمية الجيدة:
https://example.com/api/book/3تسمية سيئة:
http://example.com/api/books/34. استخدم الأحرف الصغيرة
يجب عليك كتابة جميع عناوين URL بأحرف صغيرة. يتضمن هذا عناوين URL لنقطة نهاية API. هنا مثال:
التسمية الجيدة:
http://example.com/api/Books/3تسمية سيئة:
http://example.com/api/books/35. استخدم الواصلات لفصل الكلمات
استخدم الواصلات للفصل بين الكلمات المركبة. ينتج عن الواصلات عبارات أكثر قابلية للقراءة من حالة الجمل أو الشرطات السفلية. كما أنها أفضل لأغراض تحسين محركات البحث (SEO).
التسمية الجيدة:
https://example.com/api/books/33/front_coverتسمية سيئة:
https://example.com/api/books/33/front-cover6. لا تقم بإضافة ملحقات الملفات
لست بحاجة إلى إضافة امتداد ملف إلى نقاط نهاية API الخاصة بك. على الرغم من أنه لا يؤثر على الإخراج ، إلا أن الامتداد يجعل قراءة المورد أكثر صعوبة. كما أنه يجعل المورد أقل مرونة ، مما يؤدي إلى كسره إذا تغير الامتداد في المستقبل.
التسمية الجيدة:
https://example.com/api/books.xmlتسمية سيئة:
https://example.com/api/books7. تضمين الإصدار
يجب عليك دائمًا تسمية نقاط نهاية API وفقًا للإصدار. هذا مهم إذا كنت تجري تغييرات كبيرة على API. يساعد على التمييز بين نسختين أو أكثر من إصدارات API حيث يأتي المورد. يمكنك الإشارة إلى الإصدار في بداية نقطة النهاية.
على سبيل المثال:
https://example.com/api/v3/booksلماذا تفكر في أفضل ممارسات API؟
أصبحت واجهات برمجة التطبيقات (API) العمود الفقري للبرمجة الحديثة. إنها تعمل على تحسين التعاون وتشجيع الابتكار وتحسين أمان التطبيق.
سواء باستخدام أدوات جديدة أو إدارة الأدوات الحالية ، تعمل واجهات برمجة التطبيقات على تبسيط العملية. لذلك من الضروري أن يكون لديك نقاط نهاية تعمل على تحسين تجربة المستخدم. تحدد تسمية وهيكل نقاط نهاية API أداء API الخاص بك.
تأكد من استخدام أفضل الممارسات لإنشاء نقاط نهاية فعالة لواجهة برمجة التطبيقات.
