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

Question

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

Например, кто-нибудь знает, используют ли зрелые сайты, такие как Facebook или Digg, свой собственный API для CRUD (создание, чтение, обновление, удаление) или у них есть свой собственный бэкэнд? Спасибо

Answer 1

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

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

Answer 2

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

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

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

То есть, следующее плохо

# 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)

Answer 3

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

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

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

Answer 4

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

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