Является ли хорошей практикой использование веб-сайта собственным API?

Ответ 1

Я сомневаюсь, что Facebook и так используют свой собственный API. Существует несколько причин не использовать собственный API для самого сайта:

• Вы можете сделать доступ к данным более результативным, используя базу данных напрямую, вместо выполнения дополнительных запросов и (де) сериализации.
• Возможно, проще реализовать эффективное кэширование с memcached и т.д.
• Важно отметить, что вам не нужно будет соответствовать вашему публичному API при расширении вашего сайта (вы не хотите часто менять свой публичный API, что будет просто раздражать всех)

Ответ 2

Я считаю хорошей идеей иметь низкоуровневый интерфейс к приложению, который можно использовать без браузера как такового, и что сайт должен использовать этот интерфейс для выполнения своих задач.

Этот интерфейс не обязательно должен быть самим API, это может быть уровень, который ниже уровня, чем API, и который используется как API, так и веб-сайтом.

Как правило, это плохая идея, если API просто дублирует веб-сайт.

i.e, плохое

# hypothetical example of bad duplication

def website_update_blog_post(request):
    user = request.username()
    ensure_logged_in(user)
    post = Posts.objects.upsert(request.post_title, request.post_body)
    trigger_notifications(post)

.....

def api_update_blog_post(user, password, title, body):
    verify_login(user, password)
    post = Posts.objects.upsert(title, body)
    trigger_notifications(post)

Ответ 3

если вы используете некоторые, например. MVC в качестве задней части, то у вас уже есть такой CRUD API, или вы можете использовать что-то вроде ORB-фреймворков, которые направлены в какую-либо сферу, например, как DB, и использовать их API для управления вашим приложением, а также может быть что-нибудь.

Но я не советую вам использовать raw SQL, особенно при запуске. так что, скажите мне серверные языки ваших предпочтений и цели веб-проекта, и сообщество может посоветовать вам некоторые новые идеи.

Ответ 4

Нет, не пишите свои собственные инструменты CRUD или ORMS. Существует достаточно фреймворков из коробки, где все тяжелая работа по созданию API/фреймворков/утилит уже сделана для вас - вы можете просто получить вознаграждение за производительность, используя их. Они также рассмотрят последствия для работы. Единственное наказание - небольшая кривая обучения для каждого.

Тем не менее, вы все равно можете определить стандартный способ/практику использования этих API для обеспечения единообразия (и удобства обслуживания), поскольку ваше приложение становится все больше и старше.

И если вы хотите еще больше защитить себя от изменений (или хеджировать свои ставки), вы можете абстрагировать сторонние компоненты и фреймворки, используя интерфейсы и инверсию зависимостей (например, DI или шаблон локатора обслуживания)