Distinção entre API e front-end

Estou tentando escrever um site comercial "padrão". Por "padrão", quero dizer que este site executa o HTML5, CSS e Javascript usual para o front-end, um back-end (para processar coisas) e executa o MySQL para o banco de dados. É um site básico de CRUD: o front-end apenas faz o que quer que o banco de dados tenha reservado; o back-end grava no banco de dados o que o usuário digita e faz algum processamento. Assim como a maioria dos sites por aí.

Ao criar meus repositórios do Github para começar a codificar, percebi que não entendo a distinção entre o front-end back-end e a API . Outra maneira de formular minha pergunta é: de onde a API entra nessa imagem?

Vou listar mais alguns detalhes e depois as perguntas que tenho - espero que isso dê a vocês uma idéia melhor de qual é minha pergunta real, porque estou tão confusa que não sei a pergunta específica a ser feita.

Mais alguns detalhes:

• Gostaria de experimentar o padrão Model-View-Controller. Não sei se isso muda a pergunta / resposta.
• A API será RESTful
• Gostaria que meu back-end usasse minha própria API em vez de permitir que o back-end trapaceie e chame consultas especiais. Eu acho que esse estilo é mais consistente.

Minhas perguntas:

• O front-end chama o back-end que chama a API? Ou o front-end chama a API em vez de chamar o back-end?
• O back-end apenas executa uma API e a API retorna o controle ao back-end (onde o back-end atua como o controlador final, delegando tarefas)?

São encorajadas respostas longas e detalhadas que explicam o papel da API ao lado do back-end do front-end. Se a resposta depender do modelo de programação (modelos diferentes do padrão Model-View-Controller), descreva essas outras formas de pensar na API. Obrigado. Estou muito confusa.

Acho que você está confuso com a maneira como o termo API está sendo mal usado e abusado por muitos desenvolvedores da web.

• API significa Application Programming Interface, ou seja, qualquer interface oficialmente especificada entre diferentes sistemas (ou partes do mesmo sistema).
• Algum tempo atrás, tornou-se importante para a inicialização da Web oferecer acesso público a alguns de seus dados internos por meio de uma API de serviço da Web, normalmente usando REST e JSON, permitindo assim que desenvolvedores de terceiros se integrassem aos seus sistemas. Os desenvolvedores da Web começaram a usar o termo "API" para significar especificamente (e somente) "serviço da web acessível ao público" e usurpá-lo para incluir sua implementação.
• Em termos de front-end e back-end, essa API de serviço da web (e sua implementação) é o back-end . Algumas partes podem ser publicamente acessíveis e outras apenas para o seu front-end.
• Um nome diferente para isso é "camada de serviço", ou seja, código que
  • representa serviços que o frontend chama
  • não contém lógica de exibição (afinal, esse é o trabalho do frontend)
  • é mais abstrato e de granulação mais grossa do que ações simples CRUD (uma chamada de serviço geralmente envolve várias ações CRUD e deve ser executada em uma transação de banco de dados).
  • contém a lógica de negócios do aplicativo

Vamos esboçar a arquitetura de um site "típico", com um "front-end" e um "back-end". E como é um site, também explicitamente teremos um "cliente". (Como não há como o JavaScript em um navegador chamar o MySQL diretamente em um servidor.)

Para maior clareza, os termos que estamos usando são:

• Cliente : o navegador compatível com HTML5, esp. o DOM e o JavaScript carregados para manipulá-lo.
• Front-End : o servidor PHP ao qual o DOM é apontado, contendo a página individual solicitada e alguns pontos de acesso XML ou JSON no estilo AJAX.
• Back-end : um servidor de banco de dados, onde o MySQL é executado.

Para um programa projetado adequadamente, cada um desses componentes possui uma API privada para se comunicar com os outros. O código PHP "front-end" não emite SELECTinstruções SQL arbitrárias diretamente, mas chama procedimentos armazenados, SQL pré-autorizado ou mesmo chamadas PHP distintas para uma instância completamente diferente do PHP que é executada no servidor back-end . Esses procedimentos armazenados ou chamadas HTTP distintas são elas próprias uma API.

A definição não muda, mesmo se permitirmos alguma impureza em nosso design. Se o seu PHParquivo grava e envia uma string SQL diretamente para o MySQL, ainda é uma API , embora seja muito incomum que é improvável que você repita.

Observe que é perfeitamente possível que o seu front-end php seja estritamente síncrono, sem nenhum vodu AJAX. Se você chamar as mesmas funções PHP externas no referido arquivo síncrono, poderá considerá-las como usando a mesma API que a versão do lado do cliente, embora o uso do termo "API" aqui possa não fornecer nenhuma clareza real.

Uma API como uma interface de programação de aplicativos , afinal, e realmente se refere a qualquer momento que um programa chama fora de seu próprio processo. Se você estiver escrevendo um projeto que possui um front-end e um back-end, sejam os AJAX / PHP / MySQL como acima ou MS Access / SQL Server, vale a pena especificar explicitamente como você se chamará, por nenhuma outra razão, além de facilitar saber onde procurar quando algo quebra.

(E o tópico da API pública é outra coisa completamente diferente. No nosso exemplo acima, apenas a URL exibida no cliente é uma "API pública". Todo o resto é, em essência, "privado". Assim, você não espera qualquer código fora do seu controle para chamar sua API interna e você nega esses resultados ou se reserva o direito de fazê-lo no futuro.

uma API lida com solicitações http como GET, POST, FETCH, DELETE ... que podem ser usadas dependendo do seu acesso ao token para recuperar dados em um formato específico, como json, xml, etc.

Esses "dados" podem ser usados ​​em seu próprio aplicativo para obter API (Application Programming Interface), que é um serviço da web acessível ao público para reunir dados que podem ser interessantes para algumas audiências.

Esses dados podem retornar um conjunto de dados que representam a falha ou recuperar dados do servidor da API

A API deve ser de back-end para que possa ser usada em qualquer ambiente de front-end. Isso significa que pode ser usado em um aplicativo da web, android, ios ... que pode lidar com solicitações https