Является ли хорошей практикой использование веб-сайта собственным API?
Хорошо ли разрабатывать API при разработке сайта, поэтому сам сайт фактически использует API? Или есть ли успех, если вы решите это сделать?
Например, кто-нибудь знает, используют ли зрелые сайты, такие как Facebook или Digg, свой собственный API для CRUD (создание, чтение, обновление, удаление) или у них есть собственный бэкэнд? Благодаря
Ответы
Ответ 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 или шаблон локатора обслуживания)