حذف اصولی API از پروژه Laravel

دلایل مختلفی ممکنه وجود داشته باشه که یک تیم توسعه‌ دهنده تصمیم بگیره قابلیت API رو از یک پروژه‌ی Laravel حذف کنه... مثلا:

 

- نیاز نداشتن به API و تمرکز روی توسعه‌ وب‌ سایت

- کاهش پیچیدگی و تمیزکاری

- کاهش دردسرهای امنیتی

- بهبود مصرف منابع سرور

چک لیست طراحی اصولی API در Java

1. Package Design Checklist

1.1. General

• 1.1.1. Favor placing API and implementation into separate packages [explain]
• 1.1.2. Favor placing APIs into high-level packages and implementation into lower-level packages [explain]
• 1.1.3. Consider breaking up large APIs into several packages [explain]
• 1.1.4. Consider putting API and implementation packages into separate Java archives [explain]
• 1.1.5. Avoid (minimize) internal dependencies on implementation classes in APIs [explain]
• 1.1.6. Avoid unnecessary API fragmentation [explain]
• 1.1.7. Do not place public implementation classes in the API package [explain]
• 1.1.8. Do not create dependencies between callers and implementation classes [explain]
• 1.1.9. Do not place unrelated APIs into the same package [explain]
• 1.1.10. Do not place API and SPI into the same package [explain]
• 1.1.11. Do not move or rename the package of an already released public API [explain]

1.2. Naming

• 1.2.1. Start package names with the company’s official root namespace [explain]
• 1.2.2. Use a stable product or product family name at the second level of the package name [explain]
• 1.2.3. Use the name of the API as the final part of the package name [explain]
• 1.2.4. Consider marking implementation-only packages by including “internal” in the package name [explain]
• 1.2.5. Avoid composite names [explain]
• 1.2.6. Avoid using the same name for both package and class inside the package [explain]
• 1.2.7. Avoid using “api” in package names [explain]
• 1.2.8. Do not use marketing, project, organizational unit or geographic location names [explain]
• 1.2.9. Do not use uppercase characters in package names [explain]