Различие между API и внешним интерфейсом

Я пытаюсь написать «стандартный» бизнес-сайт. Под «стандартным» я подразумеваю, что этот сайт работает с обычным HTML5, CSS и Javascript для внешнего интерфейса, внутреннего интерфейса (для обработки содержимого) и MySQL для базы данных. Это базовый сайт CRUD: внешний интерфейс просто создает все, что хранится в базе данных; бэкэнд записывает в базу данных все, что вводит пользователь, и выполняет некоторую обработку. Как и большинство сайтов там.

Создавая свои репозитории Github для начала кодирования, я понял, что не понимаю различия между интерфейсной частью и API . Другой способ сформулировать мой вопрос: откуда API входит в эту картину?

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

Еще несколько деталей:

• Я хотел бы попробовать шаблон Model-View-Controller. Я не знаю, меняет ли это вопрос / ответ.
• API будет RESTful
• Мне бы хотелось, чтобы мой бэкэнд использовал свой собственный API вместо того, чтобы позволить бэкэнду обманывать и вызывать специальные запросы. Я думаю, что этот стиль более последовательный.

Мои вопросы:

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

Приветствуются длинные и подробные ответы, объясняющие роль API наряду с интерфейсной частью. Если ответ зависит от модели программирования (модели, отличные от модели Model-View-Controller), пожалуйста, опишите эти другие способы мышления API. Благодарю. Я очень смущен.

Я думаю, что вас смущает то, как многие веб-разработчики злоупотребляют и злоупотребляют термином API.

• API означает интерфейс прикладного программирования, то есть любой официально указанный интерфейс между различными системами (или частями одной и той же системы).
• Некоторое время назад для веб-стартапа стало важным предложить публичный доступ к некоторым их внутренним данным через API веб-служб, обычно с использованием REST и JSON, что позволяет сторонним разработчикам интегрироваться со своими системами. Веб-разработчики начали использовать термин «API», чтобы обозначать конкретно (и только) «общедоступный веб-сервис», и неправильно использовать его для включения его реализации.
• С точки зрения внешнего интерфейса и внутреннего интерфейса этот API веб-службы (и его реализация) является внутренним . Некоторые его части могут быть общедоступными, а другие - только для вашего интерфейса.
• Другое название для этого - «сервисный уровень», то есть код, который
  • представляет услуги, которые вызывает интерфейс
  • не содержит логику отображения (в конце концов, это задача внешнего интерфейса)
  • является более абстрактным и грубым, чем простые действия CRUD (один вызов службы часто включает несколько действий CRUD и должен выполняться в транзакции базы данных).
  • содержит бизнес-логику приложения

Давайте наметим «типичную» архитектуру веб-сайта с «внешним интерфейсом» и «внутренним интерфейсом». И так как это веб-сайт, у нас также будет «клиент». (Поскольку в браузере JavaScript не может напрямую вызывать MySQL на сервере.)

Для ясности мы используем следующие термины:

• Клиент : HTML5-совместимый браузер, особенно DOM и JavaScript там загружены, чтобы манипулировать им.
• Front-End : PHP-сервер, на который указывает DOM, содержащий как отдельную запрашиваемую страницу, так и несколько точек доступа XML или JSON в стиле AJAX.
• Back-end : сервер базы данных, на котором работает MySQL.

Для правильно разработанной программы каждый из этих компонентов имеет собственный API для связи с другими. PHP-код «переднего плана» SELECTнапрямую не выдает произвольные операторы SQL , а скорее вызывает хранимые процедуры, предварительно авторизованный SQL или даже отдельные вызовы PHP для совершенно другого экземпляра PHP, который выполняется на внутреннем сервере . Эти хранимые процедуры или отдельные HTTP-вызовы сами по себе являются API.

Определение не меняется, даже если мы допускаем некоторую нечистоту нашего дизайна. Если ваш PHPфайл записывает и отправляет строку SQL непосредственно в MySQL, это все еще API , хотя и очень необычный, который вы вряд ли будете повторять.

Обратите внимание, что вполне возможно, что ваш php-интерфейс будет строго синхронным, без какого-либо AJAX-вуду. Если вы вызываете те же внешние функции PHP в указанном синхронном файле, вы можете считать, что они используют тот же API, что и версия на стороне клиента, хотя использование термина «API» здесь может не дать никакой реальной ясности.

В конце концов, API - это интерфейс прикладного программирования , который действительно относится к любому времени, когда одна программа вызывает вне своего собственного процесса. Если вы пишете проект, который имеет как внешний, так и внутренний интерфейс, будь то AJAX / PHP / MySQL, как указано выше, или MS Access / SQL Server, стоит указать подробные способы вызова друг друга, если только для того, чтобы было легче узнать, где искать, когда что-то ломается.

(А тема публичного API - это совсем другое. В нашем примере выше, только URL, отображаемый в клиенте, является «публичным API». Все остальное, по сути, «личное». Как, впрочем, вы не ожидаете любой код, находящийся вне вашего контроля, для вызова вашего внутреннего API, и вы либо полностью отрицаете такие результаты, либо оставляете за собой право сделать это в будущем.

API обрабатывает http-запросы, такие как GET, POST, FETCH, DELETE ... которые могут использоваться в зависимости от вашего доступа к токену для получения данных в определенном формате, таком как json, xml и т. д.

Эти «данные» могут быть использованы в вашем собственном приложении для получения API (Application Programming Interface), который является общедоступным веб-сервисом для сбора данных, которые могут быть интересны для определенной аудитории.

Эти данные могут возвращать набор данных, представляющих его сбой, или извлекать данные с его сервера API.

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