Como as APIs da web funcionam? [fechadas]

Ouvi falar de muitas APIs da web, como a do Facebook, Twitter etc., que ajudam terceiros a acessar e manipular dados. Gostaria de saber como uma API da web funciona. Quais são os princípios básicos de uma API da web?

Se eu quiser criar uma API para o meu site, para que as pessoas possam acessá-lo ou atualizá-lo, com o que preciso começar?

Na sua forma mais simples, você cria um conjunto de solicitações GET / POST para que qualquer pessoa possa chamar e publicar as informações nos URLs, parâmetros e efeitos. Solicitações GET para tarefas somente leitura e solicitações POST para qualquer coisa que altere os dados no servidor.

Adicione um sistema de autenticação, se necessário, e você terá uma API da Web simples.

Uma API da Web é apenas uma interface para permitir o acesso ao seu sistema (como site) por meio de métodos de solicitação HTTP padrão . Os dados em si geralmente são agrupados em algum formato padrão (como JSON ou XML ) para facilitar o manuseio.

Aqui está um exemplo de API da Web para 'TextWise'

Atualmente, estou desenvolvendo uma API para a plataforma de virtualização da minha empresa. Você pode abordá-los de várias maneiras diferentes, mas o meu favorito (e o caminho mais rápido para obter algo que as pessoas possam entender) é usar solicitações HTTP GET simples e retornar uma resposta JSON.

Meu URL é algo como isto:

domain.com/method/call/subcall?key=key&data=something

Depois, divido as variáveis ​​HTTP GET e faço o que o chamador deseja fazer com elas. Uma das maiores razões pelas quais me inscrevi como usuário beta no desenvolvimento da API do Stack Exchange foi o fato de saber que seria uma tremenda experiência de aprendizado e, de fato, foi .

Normalmente, eu retorno duas matrizes codificadas em JSON, uma delas result, que basicamente diz apenas se a chamada foi bem-sucedida e fornece um código de erro / string de erro, se não. O outro geralmente é chamado apenas data, e o conteúdo disso é descrito na documentação dessa chamada específica. Além disso, as APIs baseadas em GET são muito mais fáceis de testar e depurar.

Existem muitos outros formatos, como SOAP / XMLRPC, mas acho que escolher o JSON me oferece uma simplicidade incrível e liberdade de escolha.

Por exemplo, se eu precisar enviar muitos campos e não quiser lidar com várias variáveis ​​GET, basta fazer isso (exemplo em PHP)

$to_send = base64_encode(json_encode($some_array));

Isso é facilmente decodificado do outro lado, dando-me dezenas de variáveis ​​para trabalhar, enquanto ainda aceito apenas 2 - 3 variáveis ​​GET por meio da API.

Eu apenas tento manter meus métodos e chamadas curtos e sucintos, e projetá-los de tal maneira que cada chamada retorne uma resposta uniforme 'trabalhada ou com falha', seguida pelos dados solicitados.

Essa é realmente uma pergunta muito ampla. No sentido mais básico, uma API da web funciona quando um cliente (como um navegador da Web) faz uma solicitação HTTP de algum tipo para um servidor da Web. O servidor examina essa solicitação para descobrir o que o usuário deseja e, em seguida, retorna os dados em algum formato (como uma página) que o cliente examina para obter o que deseja. Essas são apenas as únicas coisas que as APIs da Web têm em comum; Percebo que isso realmente não responde à sua pergunta, mas eu queria explicar por que a pergunta é tão ampla.

Existem várias maneiras pelas quais um cliente pode formatar sua solicitação ou um servidor pode formatar sua resposta. Portanto, para que qualquer uma delas faça sentido, o cliente e o servidor precisam concordar com algumas regras básicas. De um modo geral, hoje em dia existem dois estilos muito gerais que são usados ​​para esse tipo de coisa.

Chamada de procedimento remoto (RPC)

Em uma API de estilo RPC, geralmente há apenas um URL para toda a API. Você o chama postando um documento de algum tipo que contém informações sobre o que você deseja fazer e o servidor retorna o documento que possui o que você deseja. Em termos gerais de computação, o documento de solicitação normalmente possui um nome de função e alguns argumentos.

Alguns padrões para esse estilo de API incluem XML-RPC e SOAP. Esses padrões tentam criar um formato que possa ser usado para descrever as chamadas de função que você está fazendo ou mesmo para descrever toda a API.

Transferência de estado representacional (REST)

Em uma API de estilo REST, você não tem um URL para a API como um espaço de nome : um servidor ou uma pasta dentro de um servidor, onde muitos objetos diferentes residem, e cada URL desse espaço de nome se torna parte da API. Ao invés de dizer ao servidor que deseja usar a API, o URL diz ao servidor que você quer usar a API em . Em seguida, você usa o método HTTP e, possivelmente, o corpo da solicitação, para explicar o que deseja fazer com esse objeto: GET (recuperar algo que já existe), POST (criar algo novo), PUT (substituir algo que já existe) ou DELETE (livre-se de algo que já está lá). Existem alguns outros verbos que você pode usar, mas esses são de longe os mais comuns.

Até agora, não mencionei formatos padrão para o REST. Em teoria, você poderia usar praticamente qualquer formato. O HTTP já fornece o que você deseja fazer e o que deseja, para que o formato do corpo da solicitação possa ser qualquer coisa: alguma representação do objeto que você deseja criar ou substituir. Mas, na prática, os autores do REST tendem a concordar com um formato de qualquer maneira, porque seria difícil entender todos os formatos possíveis.