Я пытаюсь написать «стандартный» бизнес-сайт. Под «стандартным» я подразумеваю, что этот сайт работает с обычным HTML5, CSS и Javascript для внешнего интерфейса, внутреннего интерфейса (для обработки содержимого) и MySQL для базы данных. Это базовый сайт CRUD: внешний интерфейс просто создает все, что хранится в базе данных; бэкэнд записывает в базу данных все, что вводит пользователь, и выполняет некоторую обработку. Как и большинство сайтов там.
Создавая свои репозитории Github для начала кодирования, я понял, что не понимаю различия между интерфейсной частью и API . Другой способ сформулировать мой вопрос: откуда API входит в эту картину?
Я собираюсь перечислить еще некоторые детали и затем вопросы, которые у меня есть - надеюсь, это даст вам, ребята, лучшее представление о том, каков мой настоящий вопрос, потому что я так растерялся, что не знаю, какой конкретный вопрос задать.
Еще несколько деталей:
- Я хотел бы попробовать шаблон Model-View-Controller. Я не знаю, меняет ли это вопрос / ответ.
- API будет RESTful
- Мне бы хотелось, чтобы мой бэкэнд использовал свой собственный API вместо того, чтобы позволить бэкэнду обманывать и вызывать специальные запросы. Я думаю, что этот стиль более последовательный.
Мои вопросы:
- Вызывает ли передний конец серверный, который вызывает API? Или внешний интерфейс просто вызывает API вместо вызова внутреннего?
- Бэкэнд только выполняет API, и API возвращает управление бэкэнду (где бэкэнд действует как главный контроллер, делегируя задачи)?
Приветствуются длинные и подробные ответы, объясняющие роль API наряду с интерфейсной частью. Если ответ зависит от модели программирования (модели, отличные от модели Model-View-Controller), пожалуйста, опишите эти другие способы мышления API. Благодарю. Я очень смущен.
Давайте наметим «типичную» архитектуру веб-сайта с «внешним интерфейсом» и «внутренним интерфейсом». И так как это веб-сайт, у нас также будет «клиент». (Поскольку в браузере JavaScript не может напрямую вызывать 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.
источник