Interface Lógica

Conceito:

Interface lógica é responsável por intermediar a interação e fazer a comunicação entre sistemas diferentes para obter as respostas relacionadas a sua ação. Interface lógica ou de software é o meio de contato predominantemente cognitivo que faz uso de aspectos léxicos (funcionais), sintáticos (estruturais) es semânticos (conteúdo).

Interface de programação de aplicação (API)

O API (Application Programming Interface), é um conjunto de rotinas e padrões estabelecidos por um software para a utilização das suas funcionalidades por aplicativos que não pretendem envolver-se em detalhes da implementação do software, mas, apenas usar seus serviços, ou seja, é como uma interface entre dois programas diferentes de modo que eles possam se comunicar um com o outro. Uma API é a forma que terceiros disponibilizam uma interface de modo que possamos consumir um determinado serviço deles sem nos preocuparmos com a implementação do mesmo.

Protocolo Simples de Acesso a Objetos (SOAP)

É o protocolo para troca de mensagens distribuidas. Ele se baseia na Linguagem de Marcação Extensível (XML) para seu formato de mensagem, e normalmente baseia-se em outros protocolos da camada de aplicação, mais notavelmente em chamada de procedimento remoto (RPC) e Protocolo de transferência de hipertexto (HTTP), para negociação e transmissão de mensagens. SOAP pode formar a camada base de uma pilha de protocolos de serviços Web, fornecendo um arcabouço básico de mensagens sob o qual se podem construir os serviços Web. Este protocolo baseado em XML consiste de três partes: um envelope, que define o que está na mensagem e como processá-la, um conjunto de regras codificadas para expressar instâncias do tipos de dados definidos na aplicação e uma convenção para representar chamadas de procedimentos e respostas.

Sua especificação define um arcabouço que provê maneiras para se construir mensagens que podem trafegar através de diversos protocolos e que foi especificado de forma a ser independente de qualquer modelo de programação ou outra implementação específica. Por não se tratar de um protocolo de acesso a objetos, o acrônimo não é mais utilizado.

Geralmente servidores SOAP são implementados utilizando-se servidores HTTP, embora isto não seja uma restrição para funcionamento do protocolo. As mensagens SOAP são documentos XML que aderem a uma especificação W3C.

O primeiro esforço do desenvolvimento do SOAP foi implementar RPCs sobre XML

Envelope das mensagens, regras de codificação, convenção RPC, ligação com protocolos subjacentes.

O SOAP tem:

• mecanismo para definir a unidade de comunicação,
• mecanismo para lidar com erros,
• mecanismo de extensão que permite evolução,
• mecanismo entre as mensagens SOAP e o HTTP, que permite representar tipos de dados em XML.

Transferência de Estado Representacional (REST)

Representational State Transfer (REST) é uma abstração da arquitetura da World Wide Web (Web), um estilo arquitetural que consiste de um conjunto coordenado de restrições arquiteturais aplicadas a componentes, conectores e elementos de dados dentro de um sistema de hipermídia distribuído. O REST ignora os detalhes da implementação de componente e a sintaxe de protocolo com o objetivo de focar nos papéis dos componentes, nas restrições sobre sua interação com outros componentes e na sua interpretação de elementos de dados significantes.

O termo transferência de estado representacional foi introduzido e definido no ano de 2000 por Roy Fielding, um dos principais autores da especificação do protocolo HTTP que é utilizado por sites da Internet, em uma tese de doutorado (PHD) na UC Irvine.[1] A REST tem sido aplicada para descrever a arquitetura web desejada, identificar problemas existentes, comparar soluções alternativas e garantir que extensões de protocolo não violem as principais restrições que fazem da Web um sucesso. Fielding desenvolveu a REST em colaboração com seus colegas enquanto trabalhava no HTTP 1.1 e nos Identificadores de Recursos Uniformes.

O estilo arquitetural de REST também é aplicado no desenvolvimento de serviços Web. Pode-se caracterizar os web services como "RESTful" se eles estiverem em conformidade com as restrições descritas na seção restrições arquiteturais.

“ A REST (Transferência do Estado Representativo) é pensada como uma imagem do design da aplicação se comportará: uma rede de sítios da Teia (um estado virtual), onde o utilizador progride com uma aplicação clicando em vínculos (transições do estado), tendo como resultado a página seguinte (que representa o estado seguinte da aplicação) que está sendo transferida ao utilizador e apresentada para seu uso. ” O termo REST se referia, originalmente, a um conjunto de princípios de arquitetura (descritos mais abaixo), na atualidade se usa no sentido mais amplo para descrever qualquer interface web simples que utiliza XML (ou YAML, JSON, ou texto puro) e HTTP, sem as abstrações adicionais dos protocolos baseados em padrões de trocas de mensagem como o protocolo de serviços Web SOAP. É possível desenhar sistemas de serviços Web de acordo com o estilo arquitetural REST descrito por Fielding, e também é possível desenhar interfaces XMLHTTP de acordo com o estilo de RPC mas sem utilizar SOAP. Estes usos diferentes do termo REST causam certa confusão em discussões técnicas, onde RPC não é um exemplo de REST.

Exemplos de códigos:

• API

Login no Facebbok via Java Scritp

$('#bt-facebook').click( function(event){
   event.preventDefault();    
   destino = this.href;
   FB.login( function(response){
       if (response.authResponse) {
           document.cookie = 'meuapp_userid='+response.authResponse.userID;
           document.cookie = 'meuapp_token='+response.authResponse.accessToken;
           window.location.href = destino;
       }else{
           // console.log('O usuário Cancelou o login ou não autozirou.');
       }
   }, {scope: 'user_photos, publish_actions'});    
});

• SOAP

Exemplo de um envelope SOAP que transporta um objeto com o nome "RevistaNome".

</xml version="1.0"?>
 <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
   <soap:Header>
   </soap:Header>
   <soap:Body>
     <m:GetRevista xmlns:m="http://www.example.org/revista">
       <m:RevistaNome>Java Magazine</m:ResvistaNome>
     </m:GetRevista>
   </soap:Body>
 </soap:Envelope>

• REST

Vamos imaginar um exemplo de um serviço de bookmark, onde o usuário pode guardar seus links favoritos, e suponhamos que este esteja localizado na URL http://mybookmarks.com. Para recuperarmos a lista de todos os bookmarks, pensando segundo a filosofia REST, teríamos que utilizar o método HTTP GET na URL que representa a lista. Por exemplo:

GET http://mybookmarks.com/bookmarks

A resposta dessa requisição poderia ser algo do tipo:

<bookmarks>
<bookmark>
<id>1</id>
<title>Google</title>
<url>http://google.com</url>
</bookmark>
<bookmark>…</bookmark>
</bookmarks>

Referências Bibliográfica:

• Irla Rebelo - https://irlabr.wordpress.com/apostila-de-ihc/parte-1-ihc-na-pratica/introducao-a-interacao-entre-homem-e-computador-ihc/
• https://pt.wikipedia.org/wiki/Interface_de_programa%C3%A7%C3%A3o_de_aplica%C3%A7%C3%B5es
• https://fxcosta.wordpress.com/2015/05/31/diferenca-entre-api-e-web-service-de-maneira-simples/
• https://pt.wikipedia.org/wiki/SOAP
• https://pt.wikipedia.org/wiki/REST
• http://www.devmedia.com.br/
• https://tableless.com.br/facebook-api-sdk-php-na-pratica-e-preview-de-como-aprovar-seu-aplicativo/