Projeto API: Expor XML ou objetos

Question

Estamos embarcando em um novo serviço de camada intermediária que permitirá que sistemas clientes internos para criar e atualizar registros e consulta em algumas lojas de dados subjacentes. O serviço irá agregar até 3 armazenamentos de dados subjacentes separadas. Para efeitos da presente questão assume:

Armazenamento de dados # 1:. Proprietary banco de dados XML
armazenamento de dados # 2: Off the shelf banco de dados relacional
. armazenamento de dados. # 3: armazenamento de arquivos Flat (arquivos armazenados como binário)

Os clientes não vai saber (nem cuidados) que armazenamento de dados que está consultando / udpating. O novo serviço vai tomar essa decisão. A minha pergunta é esta: Se o meu API expor XML ou objetos? Por exemplo. A nova API terá um método add. Supondo que o nosso sistema é um sistema de armazenamento de carro, em seguida, o método add da API pode ser parecido com isto:

AddNewCar( CarObject car )

ou, poderia ficar assim:

AddNewCar( string carXml )

Agora, mesmo que o 2º método é fracamente tipado na entrada, o XML será imediatamente validados contra esquema como um mínimo.

O novo serviço vai ser escrito em C # (não decidiu ainda sobre qual versão, mas provavelmente 3 / 3.5 com WCF). Clientes da API pode ser C # / VBA / VB.Net / C ++ / Java).

Qualquer mais detalhes por favor me avise. Graças

---

Update: Note que a API também será a publicação de XML através de um barramento de mensagens. Por exemplo. quando um carro novo é acrescentado o XML carro será publicado para que quem está interessado em carros novos serão notificados.

Answer 1

Eu diria que expor um objeto API. Apesar de não ser pelas razões mencionadas em outro post acima -. Que de expor XML resultante em um formato fixo que é mais difícil de mudança

Provavelmente, uma API de negócios fortemente tipados objetos é tão difícil de mudança como XML - tanto exigirá re-compilação e re-construção. Então, essa não é a razão pela qual você deve descartar XML.

A razão - IMNSHO - é a do nível de abstração. Ao nível da API, você está falando em termos do que objetos de negócios ou serviços pode executar que ações em que outros objetos de negócios. Portanto, a API deve falar em termos de objetos de negócios.

Como mencionado em outro post aqui, já que você pode sempre voltar os objetos de negócios com representações XML. Manter as representações XML de seus objetos de negócios e serviços em um nível inferior de abstração que a sua API irá fornecer-lhe toda a flexibilidade de XML e, ao mesmo tempo que lhe permite construir uma API de nível superior que tem boas semântica.

Answer 2

Você não deve expor o XML como isso corrige o formato e futuras decisões que você pode enfrentar em relação a infra-estrutura. Eu sempre ir a rota fortemente tipado para garantir que você adequadamente abstrato sua implementação longe de uso.

Se você tomar a rota XML e descobrir, a meio do desenvolvimento, que o XML tem de mudar, por algum motivo, será muito mais difícil de mudar todos os usos de sua API para corrigir esse problema do que se você digitou fortemente a API e escondeu o detalhe XML por trás dos objetos.

Answer 3

Você deve criar a API usando objetos e WCF alavancagem para fornecer uma API XML, se necessário.

Answer 4

Você deve criar uma API usando objetos e, em seguida, criar uma interface de serviço web em torno dessa API (por exemplo, para Java você usaria java2wsdl em sua interface, e depois wsdl2java para criar uma implementação do lado do servidor ou do lado do cliente implementação esqueleto , tenho certeza de que uma metodologia equivalente existe no WCF) que todos os outros sistemas podem consultar.

Como você tem clientes em vários idiomas, eu acho que um serviço web é a sua melhor escolha, e (ignorando a implementação lógica de negócio) está a apenas alguns minutos de trabalho em cima de sua API. Você pode distribuir seus arquivos WSDL ou XSD para todos os desenvolvedores do software cliente que se pode usar para interface para o seu sistema de forma simples e rápida.

Answer 5

Certamente a abordagem stongly digitado será mais fácil a partir de uma perspectiva do usuário-programador final que é o que eu prefiro. No entanto, se em última análise, tudo é convertido em XML nos bastidores ou se tiver dúvidas wich aproximar seus clientes levará, eu definitivamente recomendo que você apoiar ambos.