5 قواعد ذهبية لتصميم رائع لواجهة برمجة تطبيقات الويب

هل وجدت نفسك تتساءل "بماذا كانوا يفكرون؟" عند دمج خدمة ويب عبر واجهة برمجة التطبيقات الخاصة بها؟ إذا لم يكن الأمر كذلك ، فقد كنت محظوظًا أكثر مني.

يعرف أي مطور برامج مدى سهولة السماح للمشروع بالانتقال إلى رمز سباغيتي ، كما أن واجهات برمجة تطبيقات الويب ليست أقل عرضة للتسبب في شبكة ويب متشابكة. لكن لا يجب أن يكون الأمر على هذا النحو. في الحقيقة ، من الممكن تصميم واجهات برمجة تطبيقات ويب رائعة سيستمتع الأشخاص باستخدامها ، وستستمتع أيضًا بإنشائها. ولكن كيف؟ الجواب على هذا السؤال هو ما يدور حوله هذا المنشور.

إنطباع

في معظم الأوقات عندما تقوم ببناء الحلول ، فإنك تصمم للمستخدمين النهائيين الذين ليسوا مبرمجين ، أو الذين ليسوا بشكل عام متطورين تقنيًا. أنت تمنحهم واجهة رسومية ، وإذا كنت تقوم بعملك بشكل صحيح ، فقد استخلصت منهم فكرة جيدة عما يحتاجون إلى الواجهة للقيام به.

لكن تطوير API مختلف. أنت تصمم واجهة للمبرمجين ، ربما بدون معرفة من هم. ومهما كانوا ، سيكون لديهم التطور التقني (أو على الأقل سيعتقدون أن لديهم التطور التقني) للإشارة إلى كل عيب صغير في برنامجك. من المحتمل أن يكون المستخدمون لديك ينتقدون واجهة برمجة التطبيقات الخاصة بك كما هو الحال بالنسبة لهم ، وسوف يستمتعون تمامًا بانتقادها.

وهنا يكمن جزء من السخرية بالمناسبة. إذا كان يجب على أي شخص فهم كيفية إنشاء واجهة برمجة تطبيقات ويب سهلة الاستخدام ، فهو أنت . بعد كل شيء ، أنت مهندس برمجيات تمامًا مثل مستخدمي واجهة برمجة التطبيقات الخاصة بك ، لذا فأنت تشارك وجهة نظرهم. أليس كذلك؟

حسنًا ، بينما تفهم بالتأكيد وجهة نظرهم ، فأنت لا تشارك بالضرورة وجهة نظرهم. عندما تقوم بتطوير أو تحسين واجهة برمجة التطبيقات الخاصة بك ، يكون لديك منظور مصمم واجهة برمجة التطبيقات بينما لديهم منظور مستخدم واجهة برمجة التطبيقات.

يركز مصممو واجهة برمجة التطبيقات عادةً على أسئلة مثل "ماذا تحتاج هذه الخدمة أن تفعل؟" أو "ما الذي تحتاج هذه الخدمة لتقديمه؟" ، بينما يركز مستخدمو واجهة برمجة التطبيقات على "كيف يمكنني استخدام واجهة برمجة التطبيقات هذه للقيام بما أحتاجه؟" ، أو بشكل أكثر دقة ، "كيف يمكنني إنفاق الحد الأدنى من الجهد للحصول على ما أحتاجه من واجهة برمجة التطبيقات هذه؟" .

تؤدي هذه الأسئلة المختلفة إلى منظورين مختلفين اختلافًا كبيرًا. نتيجة لذلك ، فإن الشرط الأساسي الضروري لتصميم واجهة برمجة تطبيقات رائعة هو تحويل وجهة نظرك من منظور مصمم واجهة برمجة التطبيقات إلى منظور مستخدم واجهة برمجة التطبيقات. بعبارة أخرى ، اسأل نفسك باستمرار الأسئلة التي قد تطرحها بشكل طبيعي إذا كنت مستخدمًا خاصًا بك. بدلاً من التفكير فيما يمكن أن تفعله واجهة برمجة التطبيقات الخاصة بك ، فكر في الطرق المختلفة التي قد تحتاجها أو ترغب في استخدامها ، ثم ركز على جعل هذه المهام أسهل ما يمكن لمستخدمي واجهة برمجة التطبيقات الخاصة بك.

على الرغم من أن هذا قد يبدو سهلاً وواضحًا ، إلا أنه من المذهل كيف تبدو واجهات برمجة التطبيقات (API) بشكل غير متكرر وكأنها مصممة بهذه الطريقة. فكر في واجهات برمجة التطبيقات التي واجهتها في حياتك المهنية. كم مرة يبدو أنها صُممت مع وضع هذا المنظور في الاعتبار؟ يمكن أن يكون تصميم واجهة برمجة تطبيقات الويب أمرًا صعبًا.

مع ذلك ، دعنا ننتقل ونتحدث عن القواعد الذهبية الخمس لتصميم واجهة برمجة تطبيقات ويب رائعة ، وهي:

1. توثيق
2. الاستقرار والاتساق
3. المرونة
4. حماية
5. سهولة التبني

القاعدة 1: التوثيق

توثيق. نعم ، سأبدأ من هنا.

هل تكره التوثيق؟ حسنًا ، يمكنني أن أتعاطف ، لكن ارتدي قبعة "منظور المستخدم" الخاصة بك وأراهن أن الشيء الوحيد الذي تكرهه أكثر من الاضطرار إلى كتابة الوثائق هو محاولة استخدام واجهة برمجة تطبيقات غير موثقة. انهيت قضيتي.

خلاصة القول هي أنه إذا كنت تريد أن يستخدم أي شخص واجهة برمجة التطبيقات الخاصة بك ، فإن التوثيق ضروري. عليك ببساطة أن تحصل على هذا بالشكل الصحيح. إنه أول شيء يراه المستخدمون ، لذا فهو يشبه في بعض النواحي غلاف الهدايا. قدم جيدًا ، ومن المرجح أن يستخدم الأشخاص واجهة برمجة التطبيقات الخاصة بك ويتحملوا أي خصوصيات.

فكيف نكتب وثائق جيدة؟

الجزء السهل نسبيًا هو توثيق طرق API نفسها ؛ على سبيل المثال ، أمثلة للطلبات والردود ، إلى جانب أوصاف كل عنصر من العناصر في كليهما. لحسن الحظ ، هناك عدد متزايد من أدوات البرامج التي تسهل وتبسط مهمة إنشاء الوثائق. أو يمكنك كتابة شيء ما بنفسك يتفحص واجهة برمجة التطبيقات ونقاط النهاية والوظائف وينشئ الوثائق المقابلة لك.

ولكن ما يفصل التوثيق الرائع عن التوثيق المناسب هو تضمين أمثلة الاستخدام ، ومن الناحية المثالية ، البرامج التعليمية. هذا ما يساعد المستخدم على فهم واجهة برمجة التطبيقات الخاصة بك ومن أين يبدأ. يوجههم ويساعدهم على تحميل API الخاص بك في عقولهم.

على سبيل المثال ، إذا قام مطورو Twilio بإدراج كل فئة وكل طريقة وكل استجابة ممكنة لواجهة برمجة التطبيقات الخاصة بهم ، لكنهم لم يكلفوا أنفسهم عناء ذكر أنه يمكنك إرسال رسالة نصية قصيرة أو تتبع مكالمة أو شراء رقم هاتف من خلال واجهة برمجة التطبيقات الخاصة بهم ، سيستغرق الأمر وقتًا طويلاً جدًا لمستخدم واجهة برمجة التطبيقات للعثور على تلك المعلومات وفهمها بشكل متماسك. هل يمكنك أن تتخيل الفرز من خلال شجرة عملاقة من الفئات والأساليب دون أي نظرة ثاقبة لما تم استخدامها من أجله ، بخلاف أسمائها؟ يبدو فظيعا أليس كذلك؟ ولكن هذا هو بالضبط ما يفعله العديد من مزودي واجهة برمجة التطبيقات ، مما يترك واجهات برمجة التطبيقات الخاصة بهم غير شفافة لأي شخص غير أنفسهم. دليل مطور Rackspace CloudFiles ودليل API هو أحد الأمثلة ؛ من الصعب الحصول على اتجاهاتك إلا إذا كنت تفهم بالفعل ما يفعلونه وما يقدمونه.

لذا اكتب دروسًا موجزة تساعد المطور على العمل بسرعة ، مع هيكل عظمي على الأقل لما يحاول القيام به ، ثم قم بتوجيههم في اتجاه قائمة الوظائف الأكثر تفصيلاً والموثقة بالكامل حتى يتمكنوا من التوسع على ما لديهم.

بمجرد الانتهاء من الوثائق الخاصة بك ، تأكد من التحقق من صحة أنها منطقية لأشخاص آخرين غيرك. أرسلها إلى المطورين الآخرين في شبكتك ، ولا تعطهم أي تعليمات بخلاف توجيههم إلى الوثائق ، واطلب منهم اتباع برنامج تعليمي أو إنشاء شيء أساسي حقًا في حوالي 15 دقيقة. إذا لم يتمكنوا من الحصول على تكامل أساسي مع واجهة برمجة التطبيقات الخاصة بك في 15 دقيقة ، فلديك المزيد من العمل للقيام به.

للحصول على بعض الأمثلة الجديرة بالملاحظة من الوثائق الممتازة والمفصلة ، تحقق من Twilio و Django و MailChimp. لا تعتبر أي من هذه المنتجات بالضرورة الأفضل في أسواقها (على الرغم من أنها جميعًا منتجات جيدة) ، إلا أنها تميز نفسها من خلال توفير بعض أفضل الوثائق داخل أسواقها ، مما سهل بالتأكيد قبولها على نطاق واسع وحصتها في السوق.

القاعدة 2: الاستقرار والاتساق

إذا سبق لك استخدام واجهة برمجة تطبيقات Facebook ، فأنت تعرف عدد مرات إهمالهم وإعادة كتابة واجهات برمجة التطبيقات الخاصة بهم بالكامل. بغض النظر عن مدى احترامك لثقافة المتسللين أو منتجهم ، فإن منظورهم ليس صديقًا للمطورين. سبب استمرار نجاحهم هو أن لديهم مليار مستخدم ، وليس لأن واجهة برمجة التطبيقات الخاصة بهم رائعة.

ولكن ربما لا تتمتع برفاهية قاعدة المستخدمين العملاقة هذه وحصة السوق ، لذلك ستحتاج إلى واجهة برمجة تطبيقات أقل تقلبًا ، مما يحافظ على تشغيل الإصدارات القديمة ودعمها لفترة طويلة من الزمن. ربما سنوات. لتحقيق هذه الغاية ، إليك بعض النصائح والحيل.

لنفترض ، على سبيل المثال ، أن واجهة برمجة التطبيقات الخاصة بك يمكن الوصول إليها عبر عنوان URL http://myapisite.com/api/widgets وتوفر استجابتها بتنسيق JSON. بينما قد يبدو هذا جيدًا للوهلة الأولى ، ماذا يحدث عندما تحتاج إلى تعديل تنسيق استجابة JSON؟ كل شخص مندمج معك بالفعل سوف ينكسر. أووبس.

لذا ، قم ببعض التخطيط المسبق ، وقم بإصدار نسخة من واجهة برمجة التطبيقات الخاصة بك من البداية ، مع دمج رقم الإصدار بشكل صريح في عنوان URL (على سبيل المثال ، http://myapisite.com/api/widgets?version=1 أو http://myapisite.com/api/widgets/v1 ) حتى يتمكن الأشخاص من الاعتماد على الإصدار 1 الذي يعمل ويمكنهم الترقية إلى أي إصدار لاحق عندما يكونون مستعدين للقيام بذلك. إذا كنت بحاجة إلى التخلص التدريجي من إصدار سابق في وقت ما ، فابدأ ، ولكن أعط الكثير من الإشعارات وقدم نوعًا من خطة الانتقال.

سيتضمن مخطط URL الجيد الإصدارات الرئيسية في عنوان URL. يجب أن يؤدي أي تغيير في تنسيق الإخراج أو أنواع البيانات المدعومة إلى الوصول إلى إصدار رئيسي جديد. بشكل عام ، من المقبول الاحتفاظ بالإصدار نفسه إذا كان كل ما تفعله هو إضافة مفاتيح أو عقد إلى مخرجاتك ، ولكن لكي تكون في الجانب الآمن ، في أي وقت يتغير الإخراج ، قم بإخراج إصدار.

بالإضافة إلى كونها مستقرة بمرور الوقت ، يجب أن تكون واجهات برمجة التطبيقات متسقة داخليًا. لقد رأيت العديد من واجهات برمجة التطبيقات التي تغير أسماء المعلمات أو طرق نشر البيانات ، اعتمادًا على نقطة النهاية المستخدمة. بدلاً من ذلك ، يجب عليك التعامل مع المعلمات العامة بشكل عام داخل واجهة برمجة التطبيقات الخاصة بك واستخدام الميراث أو بنية مشتركة لإعادة استخدام نفس اصطلاحات التسمية ومعالجة البيانات بشكل متسق عبر واجهة برمجة التطبيقات الخاصة بك.

أخيرًا ، تحتاج إلى تسجيل ونشر سجل التغيير لإظهار الاختلافات بين إصدارات واجهة برمجة التطبيقات الخاصة بك حتى يعرف المستخدمون بالضبط كيفية الترقية.

المادة 3: المرونة

إدخال القمامة ، إخراج القمامة (GIGO) هو شعار معروف جيدًا لمعظم المبرمجين. كما هو مطبق على تصميم واجهة برمجة تطبيقات الويب ، يميل هذا المبدأ التوجيهي إلى إملاء نهج صارم إلى حد ما لطلب التحقق من الصحة. يبدو رائعا ، أليس كذلك؟ لا توجد فوضى ، لا مشكلة.

لكن كما هو الحال مع كل شيء ، يجب أن يكون هناك بعض التوازن. نظرًا لأنه من غير الممكن توقع كل الطرق التي سيرغب بها المستخدمون في استخدام خدمتك ، وبما أنه ليس كل منصة عميل متسقة (على سبيل المثال ، ليس كل نظام أساسي لديه دعم JSON جيد جدًا ، ومكتبة OAuth مناسبة ، وما إلى ذلك) ، فمن الجيد لديك على الأقل درجة معينة من المرونة أو التسامح فيما يتعلق بقيود الإدخال والإخراج.

على سبيل المثال ، ستدعم العديد من واجهات برمجة التطبيقات مجموعة متنوعة من تنسيقات الإخراج ، مثل JSON و YAML و XML و et. al. ، ولكنها ستدعم فقط تحديد التنسيق في عنوان URL نفسه. انطلاقًا من روح المرونة ، يمكنك السماح بتحديد ذلك أيضًا في عنوان URL (على سبيل المثال ، /api/v1/widgets.json ) ، أو يمكنك أيضًا قراءة Accept: application/json HTTP header أو دعم متغير سلسلة الاستعلام مثل ?format=JSON وما إلى ذلك.

وأثناء وجودنا فيه ، لماذا لا نسمح بالتنسيق المحدد بأن يكون غير حساس لحالة الأحرف ، حتى يتمكن المستخدم من تحديد ?format=json أيضًا؟ هذا مثال كلاسيكي على طريقة لتخفيف الإحباط غير الضروري لمستخدم واجهة برمجة التطبيقات الخاصة بك.

مثال آخر هو السماح بطرق مختلفة لإدخال المتغيرات. لذا ، مثلما لديك مجموعة متنوعة من تنسيقات الإخراج ، اسمح بمجموعة متنوعة من تنسيقات الإدخال أيضًا (على سبيل المثال ، متغيرات POST العادية ، JSON ، XML ، إلخ). يجب أن تدعم على الأقل متغيرات POST القياسية ، كما أن العديد من التطبيقات الحديثة تدعم JSON أيضًا ، لذا فإن هذين هما مكانان جيدان للبدء.

النقطة المهمة هنا هي أنه لا يجب أن تفترض أن كل شخص يشاركك تفضيلاتك الفنية. مع القليل من البحث حول كيفية عمل واجهات برمجة التطبيقات الأخرى ، ومن خلال الحوار مع المطورين الآخرين ، يمكنك استخلاص البدائل القيمة الأخرى المفيدة وتضمينها في واجهة برمجة التطبيقات الخاصة بك.

المادة 4: الأمن

من الواضح أن الأمان هو أحد أهم الأشياء التي يجب تضمينها في خدمة الويب الخاصة بك ، ولكن العديد من المطورين يجعلون استخدامها صعبًا للغاية. بصفتك موفر واجهة برمجة التطبيقات ، يجب أن تقدم أمثلة قابلة للاستخدام حول كيفية المصادقة والتفويض عند الوصول إلى واجهة برمجة التطبيقات الخاصة بك. لا ينبغي أن تكون هذه مشكلة صعبة يقضي المستخدم النهائي ساعات في العمل عليها. اجعل هدفك هو عدم اضطرارهم إلى كتابة أي رمز ، أو يستغرق الأمر أقل من 5 دقائق لكتابته.

بالنسبة لمعظم واجهات برمجة التطبيقات ، أفضل مصادقة بسيطة تعتمد على الرمز المميز ، حيث يكون الرمز المميز عبارة عن تجزئة عشوائية يتم تعيينها للمستخدم ويمكنهم إعادة تعيينها في أي وقت إذا تمت سرقتها. السماح بتمرير الرمز المميز عبر POST أو رأس HTTP. على سبيل المثال ، يمكن للمستخدم (ويجب عليه) إرسال رمز SHA-1 كمتغير POST ، أو كرأس بتنسيق مثل "Authorization: da39a3ee5e6b4b0d3255bfef95601890afd80709".

أيضًا ، اختر رمزًا مميزًا آمنًا ، وليس معرفًا رقميًا قصيرًا. شيء لا رجوع فيه هو الأفضل. على سبيل المثال ، من السهل نسبيًا إنشاء رمز SHA أثناء إنشاء المستخدم وتخزينه في قاعدة البيانات. بعد ذلك ، يمكنك ببساطة الاستعلام عن قاعدة البيانات الخاصة بك عن أي مستخدمين يطابق هذا الرمز المميز. يمكنك أيضًا عمل رمز تم إنشاؤه بمعرف فريد وقيمة ملح ، شيء مثل SHA(User.ID + "abcd123") ، ثم الاستعلام عن أي مستخدم مطابق ؛ على سبيل المثال ، where TokenFromPost = SHA(User.ID + "abcd123") .

خيار آخر جيد جدًا هو OAuth 2 + SSL. يجب أن تستخدم SSL على أي حال ، ولكن OAuth 2 سهل التنفيذ بشكل معقول على جانب الخادم ، والمكتبات متاحة للعديد من لغات البرمجة الشائعة.

إذا كان من المفترض أن يكون الوصول إلى واجهة برمجة التطبيقات التي أنشأتها متاحًا على موقع ويب عام عبر JavaScript ، فأنت بحاجة أيضًا إلى التأكد من التحقق من صحة قائمة عناوين URL لكل حساب للرمز المميز. بهذه الطريقة ، لا يمكن لأي شخص فحص المكالمات إلى واجهة برمجة التطبيقات الخاصة بك ، وسرقة الرمز المميز من المستخدم الخاص بك ، واستخدامه لأنفسهم.

فيما يلي بعض الأشياء المهمة الأخرى التي يجب وضعها في الاعتبار:

• وظيفة القائمة البيضاء. تسمح لك واجهات برمجة التطبيقات (API) عمومًا بإجراء عمليات إنشاء وقراءة وتحديث وحذف أساسية للبيانات. لكنك لا تريد السماح بهذه العمليات لكل كيان ، لذا تأكد من أن كل كيان لديه قائمة بيضاء بالإجراءات المسموح بها. تأكد ، على سبيل المثال ، من أن المستخدمين المصرح لهم فقط يمكنهم تشغيل أوامر مثل /user/delete/<id> . وبالمثل ، يجب التحقق من صحة جميع الرؤوس المفيدة التي تم إرسالها في طلب المستخدم مقابل القائمة البيضاء أيضًا. إذا كنت تسمح برؤوس نوع المحتوى ، فتأكد من أن كل ما يرسله المستخدم يطابق فعليًا قائمة من أنواع المحتوى المدعومة. إذا لم يحدث ذلك ، فأرسل رسالة خطأ مثل 406 Not Acceptable response. تعد القائمة البيضاء مهمة حيث يتم إنشاء الكثير من واجهات برمجة التطبيقات تلقائيًا ، أو استخدام قائمة سوداء بدلاً من ذلك ، مما يعني أنه يجب أن تكون واضحًا بشأن ما لا تريده. ومع ذلك ، فإن القاعدة الذهبية للأمان هي أن تبدأ بلا شيء على الإطلاق ، وأن تسمح فقط صراحةً بما تريد .

• احم نفسك من تزوير الطلبات عبر المواقع (CSRF). إذا كنت تسمح بمصادقة الجلسة أو ملف تعريف الارتباط ، فأنت بحاجة إلى التأكد من أنك تحمي نفسك من هجمات CSRF. يوفر مشروع أمان تطبيق الويب المفتوح (OWASP) إرشادات مفيدة حول طرق منع هذه الثغرات الأمنية.

• التحقق من صحة الوصول إلى الموارد. في كل طلب ، تحتاج إلى التحقق من أن المستخدم مسموح له بالفعل بالوصول إلى العنصر المحدد الذي يشير إليه. لذلك ، إذا كانت لديك نقطة نهاية لعرض تفاصيل بطاقة ائتمان المستخدم (على سبيل المثال ، /account/card/view/152423 ) ، فتأكد من أن المعرف "152423" يشير إلى مورد مصرح للمستخدم حقًا بالوصول إليه.

• تحقق من صحة كل المدخلات. يجب تحليل كل المدخلات من المستخدم بشكل آمن ، ويفضل استخدام مكتبة معروفة إذا كنت تستخدم مدخلات معقدة مثل XML أو JSON. لا تبني المحلل اللغوي الخاص بك ، أو ستعيش في عالم من الأذى.

المادة 5: سهولة التبني

هذه حقًا هي القاعدة الأكثر أهمية في المجموعة ، وهي تستند إلى جميع القواعد الأخرى. كما ذكرت أثناء قاعدة التوثيق ، جرب ذلك مع أشخاص جدد على واجهة برمجة التطبيقات الخاصة بك. تأكد من أنه يمكنهم بدء التشغيل والتشغيل باستخدام تطبيق أساسي على الأقل لواجهة برمجة التطبيقات الخاصة بك ، حتى لو كان يتبع برنامجًا تعليميًا فقط ، في غضون بضع دقائق. أعتقد أن 15 دقيقة هدف جيد.

فيما يلي بعض التوصيات المحددة لتسهيل وتسهيل اعتماد API الخاص بك:

• تأكد من أنه يمكن للأشخاص استخدام واجهة برمجة التطبيقات الخاصة بك بالفعل وأنها تعمل في المرة الأولى ، في كل مرة. اطلب من أشخاص جدد محاولة تنفيذ واجهة برمجة التطبيقات الخاصة بك من حين لآخر للتحقق من أنها ليست مربكة بطريقة ما تجعلك محصنًا ضدها.

• أبقيها بسيطة. لا تفعل أي مصادقة خيالية. لا تفعل بعض مخطط URL المخصص المجنون. لا تعيد اختراع SOAP أو JSON أو REST أو أي شيء. استخدم جميع الأدوات التي يمكنك تنفيذها بالفعل والتي تم قبولها على نطاق واسع ، بحيث يتعين على المطورين فقط تعلم واجهة برمجة التطبيقات الخاصة بك ، وليس API + 10 تقنيات جديدة غامضة.

• قم بتوفير مكتبات خاصة باللغة للتفاعل مع خدمتك. هناك بعض الأدوات الرائعة لإنشاء مكتبة تلقائيًا لك ، مثل Alpaca أو Apache Thrift. تدعم Alpaca حاليًا Node و PHP و Python و Ruby. يدعم Thrift C ++ و Java و Python و PHP و Ruby و Erlang و Perl و Haskell و C # و Cocoa و JavaScript و Node.js و Smalltalk و OCaml و Delphi والمزيد.

• تبسيط أي تسجيل ضروري. إذا كنت لا تطور واجهة برمجة تطبيقات مفتوحة المصدر ، أو إذا كانت هناك عملية تسجيل من أي نوع ، فتأكد من أنه عند التسجيل ، يتم توجيه المستخدم بسرعة كبيرة إلى برنامج تعليمي. واجعل عملية التسجيل آلية بالكامل دون الحاجة إلى تفاعل بشري من جانبك.

• تقديم دعم ممتاز. عائق كبير أمام التبني هو نقص الدعم. كيف ستتعامل مع تقرير الخطأ وتستجيب له؟ ماذا عن التوثيق غير الواضح؟ مستخدم غير متطور؟ تعد المنتديات وتتبع الأخطاء ودعم البريد الإلكتروني بداية رائعة ، ولكن تأكد من أنه عندما ينشر شخص ما خطأ ما ، فإنك تتعامل معه حقًا. لا أحد يريد أن يرى منتدى مدينة الأشباح أو قائمة ضخمة من الأخطاء التي لم تتم معالجتها.

ملخص واجهة برمجة تطبيقات الويب

تكثر خدمات الويب وواجهات برمجة التطبيقات الخاصة بهم. لسوء الحظ ، يصعب استخدام الغالبية العظمى. تتراوح الأسباب من سوء التصميم ، إلى نقص الوثائق ، والتقلب ، إلى الأخطاء التي لم يتم حلها ، أو في بعض الحالات ، كل ما سبق.

سيساعدك اتباع الإرشادات الواردة في هذا المنشور في التأكد من أن واجهة برمجة تطبيقات الويب الخاصة بك نظيفة وموثقة جيدًا وسهلة الاستخدام. تعد واجهات برمجة التطبيقات هذه نادرة حقًا وبالتالي فمن المرجح أن يتم تبنيها واستخدامها على نطاق واسع.