Відмінність 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 і повинен виконуватися в рамках транзакції з базою даних).
  • містить ділову логіку програми

Давайте накреслимо "типову" архітектуру веб-сайту з "переднім" та "бек-ендом". А оскільки це веб-сайт, ми також матимемо explicity "клієнта". (Оскільки JavaScript у браузері не може безпосередньо викликати MySQL на сервері.)

Для наочності використовуються такі терміни:

• Клієнт : браузер, сумісний з HTML5, esp. DOM і JavaScript там завантажені для маніпулювання ним.
• Front-End : PHP-сервер, на який вказано DOM, містить як окрему запитувану сторінку, так і деякі точки доступу XML або JSON стилю AJAX.
• Бек-енд : сервер бази даних, де працює MySQL.

Для правильно розробленої програми кожен з цих компонентів має приватний API для спілкування з іншими. "Фронтальний" PHP-код не видає довільних операторів SQL SELECTбезпосередньо, а швидше викликає збережені процедури, попередньо авторизовані 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 призначений для зворотного зв'язку, щоб його можна було використовувати в будь-якому середовищі переднього кінця. Це означає, що він може бути використаний у веб-програмі, андроїд, ios ..., яка може обробляти https-запити