به طور کلی، طراحی API کار دشواری است مخصوصاً اگر قصد طراحی برای سیستم‌های بزرگی را داشته باشیم؛ اگر شما قصد طراحی API را در سر می پرورانید که در آینده یی نه چندان دور چندین هزار کاربر از API شما استفاده خواهند کرد، حتماً می‌باید به این موضوع هم فکر کنید که تغییرات احتمالی در آینده چه اتفاقی برای کاربران رقم خواهد زد و اگر یک تغییر کوچک در API خود دادید، کاربران چگونه می‌باید با این تغییر کنار بیایند!
علاوه بر این، توجه به این نکته که کاربران API مثلاً چگونه با Override کردن برخی متدهای کلاس‌های API شما، سرویس تان را تحت تأثیر قرار خواهند داد نیز حائز اهمیت است. یکی از استراتژی هایی که توسعه‌دهندگان از آن تبعیت می‌کنند، محدود کردن سطح دسترسی کاربران است؛ به طور مثال، در زبان جاوا بسیاری از متدها را می‌توان final کرد و در زبان سی‌شارپ، می‌توان از کیورد sealed استفاده کرد تا جلوی دستکاری سیستم توسط کاربران را گرفت اما این تمام ماجرا نیست.
ما با نوشتن Unit Testها، تا حدودی می‌توانیم از صحت عملکرد API خود اطمینان حاصل کنیم اما این کافی نیست! قانون طلایی طراحی ای‌پی‌آی حاکی از آن است که «علاوه بر نوشتن یونیت تست برای ای‌پی‌آی، خود را جای کاربران ای‌پی‌آی گذاشته و اقدام به استفاده ی واقعی از ای‌پی‌آی کنید!» که در چنین شرایطی، خواهید دید که کاربران با چه مشکلاتی دست و پنجه نرم خواهند کرد، مشکلات احتمالی چیست، راه های در رو کدامند و ...
