Arquitetura de API interna e externa

A empresa em que trabalho mantém um produto SaaS de sucesso que cresceu "organicamente" ao longo dos anos. Planejamos expandir a linha com um conjunto de novos produtos que compartilharão dados com o produto existente. Para apoiar isso, buscamos consolidar a lógica de negócios em um único local: uma camada de serviço da web. A camada WS será usada por:

• As aplicações web
• Uma ferramenta para importar dados
• Uma ferramenta para integração com outro software cliente (não uma API em si)

Também queremos criar uma API que possa ser usada por nossos clientes capazes de usá-la para criar suas próprias integrações. Estamos lutando com a seguinte pergunta:

A API interna (também conhecida como camada WS) e a API externa devem ser a mesma, com configurações de segurança e permissão para controlar o que pode ser feito por quem, ou devem ser dois aplicativos separados em que a API externa apenas chama a API interna como qualquer outra aplicação? Até o momento em nosso debate, parece que separá-los pode ser mais seguro, mas aumentará a sobrecarga.

O que os outros fizeram em uma situação semelhante?

É sempre bom comer seu próprio alimento para cães. Uma API também deve ser mais simples de manter do que duas, mesmo se você considerar algumas despesas gerais para autenticação e autorização.

Embora eu concorde com o Aneurys9, às vezes você não deseja expor todos os recursos do seu sistema. Nesse caso, seria preferível ter duas APIs ... MAS, se você escolher dessa maneira ... verifique se todas as funcionalidades comuns compartilham a mesma API, ou seja, que uma seja uma versão estendida da outra, em oposição a duas distintas conjuntos de código.

Dessa maneira, você pode usar o seu próprio material enquanto mantém um espaço para o trabalho experimental privado, sensível e progredir, ao mesmo tempo em que permite publicar e usar o novo material sem alterar muito a API pública.

Eu já encontrei isso antes (muitas vezes) e o que acabei preferindo é:

Retire o BL do site. Torne o site um consumidor da API. Trate o site como apenas outro cliente da sua API. Sua API é o serviço.

Se você acha que precisa de métodos especiais de API apenas para o site, pense novamente! Se é bom para o ganso, é bom para o gander. Se você realmente precisa realmente de uma funcionalidade especial para o site, sugiro que o que você realmente encontrou seja uma diferença no "perfil do usuário" e, portanto, essa é uma situação em que a API ainda deve suportar as funções "especiais", mas você controlá-los via autorização.

Não convencido?

Dê um passo adiante no paradigma ...

O aplicativo de telefone está sendo executado em uma plataforma na qual o bytecode é executado, o aplicativo vive no telefone e consome serviços de API via HTTP / JSON

O site é um aplicativo em execução em uma plataforma na qual o HTML + Javascript é executado, o aplicativo vive no navegador e consome serviços de API via HTTP / JSON

O mesmo!

Estenda isso para tablets, TVs, outras plataformas de telefone, plugins, aplicativos de terceiros, mashups, ...

Diversas experiências de usuário diferentes, todas conectadas a uma API comum.

Seu aplicativo é a API. O site é apenas um cliente (de muitos)

Use uma API

Se você estiver implementando a API de serviço como uma camada REST, basta adicionar autenticação às rotas que estão protegidas.

Você provavelmente desejará usar uma estrutura de desenvolvimento que não produza muita 'mágica'. Algo em que você pode definir rotas diretamente sem muita engenharia reversa.

Pense em algo como Node.js / Express, python / pilões, python / google app engine, etc.

Eu recentemente implementei isso no Google App Engine para uma API REST / Datastore e não acho que poderia ter sido mais fácil. Os controladores são implementados como classes e suas solicitações HTTP subsequentes (ou seja, GET / POST / PUT / DELETE) são implementadas como métodos dessas classes. Consegui implementar o basic-auth como decorador. Isso fez com que adicionar um requisito de autenticação a uma solicitação fosse tão simples quanto anexar o decorador @basicAuth.

Dessa forma, eu poderia tornar públicas as solicitações GET recebidas, adicionar um requisito de autenticação às solicitações POST / PUT / DELETE no mesmo controlador para esse modelo.

Se você sabe falar em REST, a vida se torna muito mais fácil porque o suporte a REST já é inerentemente incorporado a um servidor da web (por exemplo, HTTP é apenas um tipo de API REST). Você pode até optar pela compactação transparente do gzip se estiver enviando muitos dados pela rede.

Minha primeira impressão é que ela deve ter a mesma API e que sua segurança deve estar em uma camada completamente diferente. Talvez manipulado por uma frente da web?