REST versus SOAP - Criação de aplicações modernas

Os desenvolvedores têm muitas opções ao criar aplicações modernas. Linguagens estáticas ou dinâmicas, recursos estabelecidos como o Java ou novidades como o Golang, frameworks multifuncionais monolíticas versus bibliotecas modularizadas, ou até mesmo executar toda a pilha em Javascript são apenas a ponta do iceberg. Uma outra decisão importante para os desenvolvedores é escolher entre REST ou SOAP.

REST e SOAP, simplesmente, são métodos de comunicação entre aplicações. Embora o objetivo final seja o mesmo, REST e SOAP não podem ser comparados diretamente, pois REST é um conjunto de diretrizes que os desenvolvedores podem optar por implementar de forma diferente em cada projeto, enquanto SOAP é um protocolo bem definido e padronizado para troca de dados. Ainda assim, é possível comparar as vantagens e desvantagens de usar um ou outro. Ambos ainda são amplamente utilizados em todo o setor, e esperamos esclarecer por que e quando você pode usar um ou outro.

O padrão de arquitetura REST (Representational State Transfer) é comumente usado no desenvolvimento de aplicações modernas baseadas na Web, como sites, aplicações móveis, jogos e muito mais. O desenvolvimento de uma API baseada em REST permite que você exponha a funcionalidade do seu serviço da web por HTTP e interaja com ele pela Web. Ao utilizar verbos de HTTP como GET e POST, o cliente instrui a API a recuperar ou criar recursos.

As APIs RESTful ganharam enorme popularidade devido à sua interoperabilidade e flexibilidade na web. Os serviços Web construídos com essa arquitetura podem evoluir independentemente das aplicações que os consomem. As APIs baseadas em REST não possuem um protocolo de segurança bem definido, mas os JSON Web Tokens (JWTs) são o método mais comum de autenticação e autorização de solicitações.

Vantagens

• Sem monitoração de estado – cada chamada para o serviço Web tem todas as informações necessárias para processar a solicitação e não depende do armazenamento do contexto cliente-servidor.
• Flexível – As APIs RESTful podem aceitar e servir dados em muitos formatos diferentes, incluindo JSON, XML, Atom e outros. JSON é de longe o formato de dados mais popular usado em APIs baseadas em REST.
• Passível de cache – as respostas podem ser armazenadas em cache, o que pode melhorar muito o desempenho do serviço Web, eliminando chamadas desnecessárias ao back-end.

Desvantagens

• Padrões – não há um padrão definido para a construção de APIs baseadas em REST. Existem muitos recursos e guias excelentes, como os padrões de API RESTful da Casa Branca e o Tutorial de API REST, mas existem muitas permutações de APIs baseadas em REST.
• HTTP – As aplicações RESTful estão limitadas ao protocolo HTTP.

O SOAP, por outro lado, é um protocolo para troca de dados. Seus pontos fortes residem no fato de ter um certo conjunto de regras e padrões que devem ser obedecidos para interações cliente/servidor bem-sucedidas. As solicitações SOAP são entregues por meio de envelopes que devem conter todas as informações necessárias para processar a solicitação.

Um envelope de solicitação SOAP geralmente consiste em um cabeçalho opcional e um atributo de corpo obrigatório. O atributo de cabeçalho é usado para informações como credenciais de segurança e outros metadados, enquanto o atributo de corpo é usado para manipular os dados reais e quaisquer erros que surjam. Esta é uma simplificação de como o SOAP lida com a troca de dados, portanto, para obter informações mais detalhadas, consulte a Especificação W3C e, se você estiver ansioso para escrever um serviço da Web SOAP, tente um tutorial fácil de seguir.

Vantagens

• WSDL – a Web Services Description Language (WSDL) descreve os métodos de serviço da web, acesso e outros parâmetros, oferecendo todo o necessário para aprender como consumir a API.
• Extensibilidade – As extensões WS-*, como WS-Security, WS-Addressing, WS-Federation e outras, podem aprimorar muito os recursos da aplicação.
• Protocolo Neutro – acessível via HTTP, SMTP, TCP e outros protocolos de nível de aplicação.

Desvantagens

• XML Infoset – SOAP usa XML para transferir dados de payload que podem levar muito mais tempo para serializar, o que leva a problemas de desempenho.
• Sintaxe complexa – O SOAP trabalha exclusivamente com XML, e a leitura dos envelopes de dados pode ser difícil e demorada.

As APIs RESTful estão em todos os lugares. De aplicações de página única à Internet das Coisas (IoT), os serviços alimentados por APIs baseadas em REST são a norma. Além dos benefícios técnicos descritos acima, as APIs baseadas em REST são uma ótima opção para muitas empresas porque geralmente são mais fáceis de entender, além de ser mais simples desenvolver para elas. REST é uma ótima opção para startups, aplicações móveis e desenvolvedores que criam aplicações de página única (SPAs) modernas.

Muitas empresas são criadas para fornecer uma API RESTful que resolve um problema singular e se integra perfeitamente a qualquer aplicação. A Auth0 é um ótimo exemplo disso. Outros casos de uso comuns para REST são empresas que expõem seu conjunto de dados e permitem que terceiros criem produtos com base na API exposta, como o Falcon App criado com base na API RESTful do Twitter.

Os serviços Web que utilizam SOAP são comumente encontrados em ambientes corporativos. Grandes ambientes corporativos, como os encontrados em bancos e serviços de saúde, se beneficiam mais com a utilização de SOAP, pois oferecem maior flexibilidade e controle sobre as interações cliente/servidor. Expressar métodos complexos geralmente é mais fácil com transações compatíveis com SOAP e ACID.

O SOAP é mais adequado para a empresa, mas isso não quer dizer que não possa ou não deva ser usado para empreendimentos menores. A única ressalva a isso é que a criação de uma aplicação SOAP geralmente leva mais tempo, portanto, se você estiver apenas experimentando uma ideia, poderá se atrapalhar com a complexidade em comparação com um código de implantação real pronto. Um teste decisivo comum no debate da comparação entre o REST e o SOAP afirma que “se você não conseguir encontrar um motivo específico para criar seu serviço Web com SOAP, use REST”.

As APIs REST são comumente autenticadas com Json Web Tokens (JWT). Se um endpoint de API precisar ser protegido, a estratégia é exigir que o cliente, ao fazer uma solicitação à API, inclua um cabeçalho de autorização que inclua um token que verifica a identidade do solicitante. O servidor então verifica se o token é válido e, se for, processa a solicitação.

Há muitos benefícios em usar a autenticação baseada em token, e você pode aprender tudo sobre eles aqui. As APIs REST não se limitam à autenticação baseada em token – você pode usar a autenticação baseada em cookie/sessão ou até mesmo criar seu próprio mecanismo de autenticação.

Com um exemplo, vamos analisar como você pode proteger sua API RESTful com JWT. Você criou uma aplicação móvel que exibe uma citação motivacional do dia. A citação diária é recuperada por meio de uma solicitação GET para sua API RESTful em /api/v1/quote. O feedback que você recebeu é ótimo, e seus usuários estão engajados. Você deseja dar a eles a funcionalidade de enviar suas próprias citações para a aplicação.

Um novo endpoint RESTful é criado para que, quando uma solicitação POST for enviada para /api/v1/quote contendo os dados necessários no corpo, a citação enviada seja salva no banco de dados para sua análise. Você não quer que qualquer pessoa lhe envie citações. Somente usuários registrados devem poder enviar. A implementação da API é assim:

...

routes.post('/api/v1/quote', function(req, res){
    // getToken é uma função auxiliar que procura uma chave de autorização
    // no cabeçalho que contém o valor 'Bearer {token}'
    // em seguida, remove a palavra-chave Bearer e retorna apenas  {token}
    var token = getToken(req.headers.authorization);
    var quote = req.body.quote;

    jwt.verify(token, 'secret', function(err, decoded){
        if(err){
            res.json(err) // Retorna detalhes de erro
        } else {
            // Save the quote to a database
            res.json({'message':'Quote Successfully Submitted. Thank you!'}); 
        }
    });
});

...

Na implementação acima, quando um usuário faz uma solicitação POST para o endpoint /api/v1/quote, extraímos o JWT e o armazenamos em uma variável chamada token. Se o cabeçalho de autorização não existir, simplesmente interrompemos a execução, pois podemos assumir com segurança que o usuário não está autenticado. Se obtivermos um token, verificamos se ele é válido. O token é verificado em relação a um segredo com o qual foi originalmente assinado. Além disso, verificamos se o token expirou. O objeto decoded pode ter dados adicionais, como permissões de usuário que podem ser adicionadas quando o token é criado, mas para nossa demonstração preservamos a simplicidade.

POST para API com JWT válido

POST para API sem JWT

Se tudo for verificado e nenhum err for retornado, sabemos que o usuário está autenticado. Assim, salvamos sua citação no banco de dados e enviamos uma mensagem gentil agradecendo por usar nossa aplicação. Neste exemplo, fizemos a verificação do token dentro da implementação do endpoint. Em um cenário do mundo real, a verificação do token seria preferencialmente feita por meio de um middleware mais acima pilha de chamadas.

A Auth0 pode usar facilmente da geração de JWTs como parte do fluxo de trabalho de autenticação. Depois que um usuário fizer login com sucesso, a Auth0 retornará um JWT, que pode ficar no armazenamento local ou em um cookie. Então, toda vez que uma solicitação é enviada para a API, você deve anexar o token no cabeçalho sob uma chave de autorização. Do lado do servidor, você precisará validar esse token, que como vimos acima é uma tarefa simples ao usar um dos muitos SDK da Auth0.

SOAP é tão flexível quanto REST quando se trata de proteger e autenticar um serviço Web. WS-Security é a extensão de chave que suporta muitos modelos de autenticação, incluindo: credenciais básicas de nome de usuário/senha, SAML, OAuth e muito mais.

Uma maneira comum de autenticar as APIs SOAP é por meio do Single Sign On (SSO) SAML. O SAML funciona facilitando a troca de credenciais de autenticação e autorização entre aplicações. Uma federação SAML é composta por três partes: o usuário, um provedor de identidade e um provedor de serviços. O usuário faz uma solicitação do provedor de serviços para um provedor de identidade e, se a solicitação for bem-sucedida, o usuário é autenticado e pode acessar a aplicação.

A implementação do SAML SSO pode ser uma tarefa assustadora, difícil e demorada. A Auth0 pode ajudar! Vamos ver com que rapidez podemos configurar o SAML SSO com SSOCircle. A Auth0 será o Provedor de Serviços, enquanto o SSOCircle será o Provedor de Identidade, o que significa que, uma vez que o usuário tente fazer login, ele será levado ao SSOCircle para verificar sua identidade.

Com uma conta SSOCircle criada, vamos obter os metadados públicos para SSOCircle. Podemos obter isso acessando https://idp.ssocircle.com/. A partir daqui, queremos obter três atributos, o KeyDescriptor Signing X509 Certificate, SingleSignOnService Redirect Location e SingleLogoutService Redirect Location.

Começaremos criando um novo arquivo .pem para armazenar o certificado criando um novo arquivo e copiando o Certificado X509. Além disso, precisaremos adicionar os delimitadores Begin e End Certificate, conforme mostrado abaixo.

-----BEGIN CERTIFICATE-----
MIIDATCCAemgAwIBAgICCpgwDQYJKoZIhvcNAQEFBQAwLjELMAkGA1UEBhMCREUx
EjAQBgNVBAoTCVNTT0NpcmNsZTELMAkGA1UEAxMCQ0EwHhcNMTEwNTE3MTkzNDEx
WhcNMjEwODE3MTkzNDExWjAuMQswCQYDVQQGEwJERTESMBAGA1UEChMJU1NPQ2ly
Y2xlMQswCQYDVQQDEwJDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
ALm1xZq5goTh7NmdzZsZUJed9+7XauwuaNuGyZpIGRo4FsP1YPgs+40mYAoa9rDj
CEekixkfSI6nBUMdHuRIMHogyu/OVxskrL91SLO5m5u9JhgIhO/s9pnmnrnNUILf
RccE4+AEO1xsBQ/x1sY2zDZk+71Pfvifc9vVxedHpNAumbe1nb+CofUtAbF6PkHv
g3pqCoMPmC7m4NAr9h+zq3ekeWf8j5SOicupet9XhsO6zUr0Wga/Zs6J0khhYmFy
zpqoP2rLJ4a/9qduSGslOWsed6kD+zvhLMAUVcw3goli4VhepNzU5iGL9QdVj7m4
YQRMofBRYyL7tBWO6jzLpFcCAwEAAaMpMCcwFAYJYIZIAYb4QgEBAQH/BAQDAgD/
MA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQEFBQADggEBAKmOo8un97VFxNgo
iAzpU5fugKdAFFnKHTvUzDLQ81O455OyT6tcAsXHz6sy2c6GozqDV7xrXSqnues8
p9/w0KzVY9/YuxB90uiSJVh0zMxS+NwyfG1Od5Brloh9eBM4YulUI3V2ustcck17
2G4X4/QSK8uo0bjELUzSNAGj7uypsKKXjX++enfAJzLSsqk3Y8Tmon4R6GYBj4mo
1nL6ujeXqB/kH44XnEmU7ojyIC1kawFRdY4GDFIq3HOBFNzlNbJVL+jKdgTQJTET
rNTDjxXmxwpZ90+lPbEaLQeElwAQi7pMtcqD/f8Dqaifk9ZvpCB7NC+oLM5ej9nK
TawsVqs=
-----END CERTIFICATE-----

Salve este arquivo como SSOCircle.pem. Navegue até o Auth0 Dashboard e crie uma nova conexão do Provedor de identidade SAMLP navegando até Conexões (Connections), depois no submenu Empresarial (Enterprise) e clicando no ícone + na seção Provedor de identidade SAMLP (SAMLP Identity Provider). Existem muitas configurações que podemos definir aqui, mas para nossa demonstração, primeiro definiremos um Nome de conexão, que pode ser qualquer coisa que você escolher. Iremos pular os domínios de e-mail para esta demonstração, mas a seção de domínios de e-mail é onde você definiria quais domínios funcionarão automaticamente com Single Sign On – normalmente será seu domínio corporativo.

As URLs de entrada e saída que recebemos dos metadados SSOCircle públicos, portanto, os inseriremos lá. A última parte da configuração é carregar o certificado .pem que criamos anteriormente. Com essas configurações definidas - podemos ignorar o resto e apenas salvar.

Depois de salvar as configurações, você será solicitado a continuar e precisará obter os metadados para sua conexão. Deve se assemelhar a:

<EntityDescriptor entityID='urn:auth0:{ACCOUNT_NAME}:{CONNECTION_NAME}' xmlns='urn:oasis:names:tc:SAML:2.0:metadata'>
  <SPSSODescriptor WantAssertionsSigned='true' protocolSupportEnumeration='urn:oasis:names:tc:SAML:2.0:protocol'>

    <SingleLogoutService Binding='urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect' Location='https://{ACCOUNT_NAME}.auth0.com/samlp/logout'/>
    <SingleLogoutService Binding='urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST' Location='https://{ACCOUNT_NAME}.auth0.com/samlp/logout'/>
    <NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</NameIDFormat>
    <NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</NameIDFormat>
    <NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat>
    <AssertionConsumerService Binding='urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST' Location='https://{ACCOUNT_NAME}.auth0.com/login/callback?connection={CONNECTION_NAME}' index='0' isDefault='true'/>
  </SPSSODescriptor>
</EntityDescriptor>

Estes são os metadados de suas conexões, e você os usará para registrar um novo Provedor de Serviços no lado do SSOCircles. Vá para SSOCircle e navegue até a seção Gerenciar metadados (Manage Metadata). Uma vez lá, clique em Adicionar novo provedor de serviços (Add New Service Provider). Você precisará inserir o nome de domínio totalmente qualificado (FQDN), que no nosso caso será auth0.com, selecionar EmailAddress nos atributos enviados na seção assertion e, finalmente, colar os Metadados XML na área de texto fornecida. Clique em enviar (submit) e você, o provedor de serviços Auth0, será registrado.

Para testar se a conexão foi bem-sucedida, clique no botão gerenciar (manage) na seção Provedor de identidade SAMLP (SAMLP Identity Provider) e depois em Tentar (que é o ícone de reprodução). Se tudo correu bem, você deve ver uma tela como esta abaixo. E pronto! Agora você integrou o SAML Single Sign On com Auth0 atuando como provedor de serviços e SSOCircle atuando como provedor de identidade. Para obter um guia mais detalhado sobre como implementar uma federação SAML, confira os docs.

Esteja você criando uma aplicação móvel que consome serviços RESTful ou uma aplicação SOAP corporativa, a Auth0 oferece cobertura quando se trata de autenticação.

A autenticação JWT é o básico da Auth0. Com uma extensa biblioteca de autenticação, bem como SDKs para muitas linguagens de programação e estruturas, você pode ter a autenticação funcionando em minutos. O suporte para mais de 30 contatos sociais, incluindo Facebook, Twitter e Google, bem como a capacidade de usar um banco de dados de usuários existente, facilita a mudança para a Auth0.

A Auth0 pode atuar tanto como Provedor de serviços quanto como Provedor de identidade em uma federação baseada em SAML. Aplicações como Salesforce ou Box podem utilizar a Auth0 como um Provedor de identidade para permitir que os usuários façam login em tais serviços por meio da Auth0. No caso de a Auth0 atuar como Provedor de serviços, ela enviará uma solicitação de autorização a um Provedor de identidade, como SSOCircle, OneLogin ou qualquer outro Provedor de identidade compatível com SAML.