Boa tarde. Alguém teria um tempo para explicar ou indicar um bom material sobre “API REST” e de quebra, o tais “Swagger” e “JSON”? Material bem inciante, por favor. Já estou trabalhando com os ditos cujos mas tah complicado de fazer as coisas sem entender como elas são ou porque são. Obrigado pela paciência!
Oi, @Giuli_Ilustre. Tranquilo?
Aqui você pode dar uma estudada sobre O que é API REST e API RESTFUL. Sobre o conceito de API, dá pra definir da seguinte forma:
O acrônimo API que provém do inglês Application Programming Interface (Em >português, significa Interface de Programação de Aplicações), trata-se de um conjunto de rotinas e >padrões estabelecidos e documentados por uma aplicação A, para que outras aplicações consigam >utilizar as funcionalidades desta aplicação A, sem precisar conhecer detalhes da implementação do software.
Desta forma, entendemos que as APIs permitem uma interoperabilidade entre aplicações . Em outras palavras, a comunicação entre aplicações e entre os usuários.
Swagger é uma ferramenta para documentação de APIs. JSON significa JavaScript Object Notation, e é um formato leve de troca de informação sobre sistemas. Você pode ler mais sobre eles nos links:
O que é JSON?
O que é Swagger?
[]'s
1 curtida
Não sei quão iniciante é você, então vou explicar o mais grosseiramente possível. Se ficar simples demais pode fazer mais perguntas.
Imagina que você tem um site, uma aplicação web que salva, exclui, atualiza e recupera anotações. Tem uma interface HTML com botões como VISUALIZAR ANOTAÇÃO, CRIAR NOVA ANOTAÇÃO, EDITAR ANOTAÇÃO, EXCLUIR ANOTAÇÃO, etc. Qualquer pessoa pode ir no seu site e adicionar ou editar uma nova anotação. Super útil e revolucionário.
Tem um outro cara, o João, que tem um site de agenda. Ele quer colocar uma opção no site dele de o usuário poder salvar a agenda dele em forma de anotação no seu site. Mas pra isso ele precisa acessar o seu site no navegador, criar no botão CRIAR NOVA ANOTAÇÃO e salvar a anotação no seu site. Ele até pode fazer isso usando algum programa de automação, mas é não é tão eficiente.
Então, você decide algo melhor. Você cria um “programa” que pode receber comandos/requisições de qualquer coisa/pessoa/sistema, pela Internet, que executa uma operação no seu site, como salvar uma anotação. A pessoa ou software que envia esse comando manda, junto com o comando, o texto que será salvo no seu site. Agora o João só precisa enviar um comando pra esse programa toda vez que um usuário quiser salvar uma agenda do site dele no seu site! 
Esse “programa” que você criou pode ser chamado de “API”. E os comandos são métodos HTTP, o protocolo mais comum na Internet (me avisa se você não sabe o que é HTTP).
A sua API começa a fazer muito sucesso. Dezenas de desenvolvedores estão integrando o site deles com o seu site de anotações. E outras pessoas estão te imitando e também criando APIs. Mas cada um tá criando do seu jeito, mandando informação do jeito que quiser, etc. Uma bagunça. Então você cria vários padrões e princípios pra que fica mais fácil de todo mundo integrar com as API dos outros. As APIs que seguem essa padrão é chamado de “API REST”.
Um outro problema é que é trabalhoso ficar criando documentação de como usar cada uma das suas APIs. E também é chato ficar usando linha de comando ou algum programa pra experimentar a sua API. Então, você desenvolve uma ferramenta que facilita a documentação e experimentação da sua API. Toda vez que alguém novo quiser aprender e experimentar a sua API ele vai poder acessar um endereço que ter listado todos os métodos da API, quais os parâmetros, que tipo são cada parâmetro, exemplos de dados que precisa ser enviado, exemplo de dados que vão ser retornados, descrição do que faz cada método, etc.
E JSON é basicamente um formato em que os dados são transferidos entre as APIs. Vocẽ poderia basicamente enviar os dados mais ou menos assim:
meuNome|João da Silva
anotacao|Eu quero salvar esta anoção no seu site blá bĺa blá.
Ou assim:
<dadoTransmitidoNaApi>
<meuNome>
"João da Silva"
</meuNome>
<anotacao>
"Eu quero salvar esta anoção no seu site blá bĺa blá."
</anotacao>
</dadoTransmitidoNaApi>
Ou assim, no formato JSON:
{
meuNome: "João da Silva",
anotacao: "Eu quero salvar esta anoção no seu site blá bĺa blá."
}
Enfim, ficou gigante. Espero que pelo menos tenha ficado didático.
1 curtida
Desculpe minha ignorância em relação ao assunto, mas não seria a mesma coisa?
Na minha concepção atual eu entendo que REST é apenas a convenção de como uma API deve ser construída, e toda API que segue esse padrão é uma API RESTFUL, ou são coisas distintas?
Acredito que faltou você fechar as tags do seu exemplo de XML.
1 curtida
Existe uma certa confusão quanto aos termos REST e RESTful. Entretanto, ambos representam os mesmo princípios. A diferença é apenas gramatical. Em outras palavras, sistemas que utilizam os princípios REST são chamados de RESTful.
- REST: conjunto de princípios de arquitetura
- RESTful: capacidade de determinado sistema aplicar os princípios de REST.
Citei os dois como “coisas separadas” por que ele é iniciante e pode se deparar com os dois termos, então é bom pesquisar sobre isso.
[]'s
1 curtida
Muito bom! Bem didático mesmo! Só uma pergunta (desculpe a leiguice):
Isso significa que a API fica na rede para qualquer programa web acessa-la?
Que bom que ficou didático
- Existem APIs que qualquer pessoa ou programa pode acessa-la.
- Existem as que permitem, mas com um limite de requisições por dia. Por exemplo, no máximo 1000 requisições por dia.
- Existem as que tem uma chave/senha e só quem tem essa chave/senha pode acessar essa API. Aí na hora que você for executar um método da API você manda essa chave junto com a requisição. Se não tiver a chave, a API retorna um ERRO e você não consegue executar o método da API.
- Existem as que geram um “bilhete”, ou um “vale-API”, que te dá uma permissão pra acessar a API por um tempo determinado. Você adquire esse “bilhete” fazendo login, por exemplo, na API. Então, só quem tem login poderia acessar essa API e por tempo limitado. Quando acabar o tempo você teria que pedir outro pra API, etc. Pra acessar os métodos permitidos você manda esse “bilhete” (que nada mais é que um código de letras e números) junto com a requisição, igual citei no exemplo anterior com as chaves.
1 curtida
Cara… sem palavras. Saber fazer e explicar o que se sabe fazer sao coisas diferentes. Vejo que você domina muito bem as duas. Muito obrigado!
1 curtida
Muito bom os links! Valeu mesmo!