Diseño API: La exposicion XML u objetos

Question

Estamos de embarcarse en un nuevo servicio de nivel medio que permita sistemas cliente interno para crear y actualizar los registros de consulta y en algunos almacenes de datos subyacentes. El servicio agregará un máximo de 3 almacenes de datos subyacentes separadas. A los efectos de esta pregunta suponer:

Los datos almacenan # 1: Propietario de base de datos XML
. almacén de datos # 2: Más allá de la base de datos relacional plataforma
. almacén de datos # 3:. almacén de archivos planos (archivos almacenados en formato binario)

Los clientes no sabrán (ni me importa), que el almacén de datos que está consultando / udpating. El nuevo servicio será tomar esa decisión. Mi pregunta es la siguiente: ¿Debería mi API XML o exponer objetos? P.ej. La nueva API tendrá un método add. Suponiendo que nuestro sistema es un sistema de almacenamiento de coche, entonces el método Add de la API puede tener este aspecto:

AddNewCar( CarObject car )

o, podría tener este aspecto:

AddNewCar( string carXml )

Ahora, a pesar de que el segundo método es tipos débiles en la entrada, el XML, inmediatamente será valida con esquema como mínimo.

El nuevo servicio va a ser escrito en C # (no decidió aún de la versión, pero probablemente 3 / 3.5 con WCF). Los clientes de la API podría ser C # / VBA / VB.Net / C ++ / Java).

Cualquier más detalles por favor hágamelo saber. Gracias

---

Actualización: Tenga en cuenta que la API también estará publicando XML a través de un bus de mensajes. P.ej. cuando se añade un nuevo coche el XML coche será publicada para que cualquiera que esté interesado en los coches nuevos será notificado.

Answer 1

Yo diría que expone una API objeto. Aunque no por las razones mencionadas en otro post anterior -. La de exponer XML resultante en un formato fijo que es más difícil de cambiar

Podría decirse que un API de objetos de negocio de tipo fuerte es tan difícil de cambiar como XML - tanto será necesario volver a compilar y re-edificio. De manera que no es la razón por la que debe descartar XML.

La razón - IMNSHO - es el de nivel de abstracción. A nivel de API, que está hablando en términos de lo que los objetos de negocio o servicios pueden realizar qué acciones sobre qué otros objetos de negocio. Por lo tanto, la API debe hablar en términos de objetos de negocio.

Como se ha mencionado en otro post ya aquí, siempre se puede hacer copias de los objetos de negocio con representaciones XML. Mantener las representaciones XML de los objetos de negocio y servicios a un nivel de abstracción más bajo que su API le proporcionará toda la flexibilidad de XML, mientras que al mismo tiempo que le permite construir una API de alto nivel que tiene buenas semántica.

Answer 2

No debe exponer el XML como esto soluciona su formato y cualquier decisión futura que se puede enfrentar con respecto a la infraestructura. Yo siempre ir a la ruta fuertemente tipado para asegurarse de que su aplicación adecuada abstracta fuera de uso.

Si se toma la ruta XML y descubrir, en mitad del proceso de desarrollo, que el XML tiene que cambiar por alguna razón, será mucho más difícil de cambiar todos los usos de su API para corregir el problema de si ha escrito fuertemente la API y ocultó los detalles detrás de los objetos XML.

Answer 3

Debe crear la API usando objetos y WCF apalancamiento para proporcionar una API XML si es necesario.

Answer 4

Debe crear una API usando objetos y, a continuación, crear una interfaz de servicios web en torno a ese API (por ejemplo, para Java que usaría Java2WSDL en su interfaz, y luego wsdl2java para crear una implementación de la aplicación del lado del servidor esqueleto o del lado del cliente estoy seguro de que existe una metodología equivalente en WCF) que todos los otros sistemas pueden consultar.

A medida que tiene clientes en varios idiomas, creo que un servicio web es su mejor opción, y (ignorando la implementación de la lógica de negocio) está a sólo unos minutos de trabajo en la parte superior de la API. Usted puede distribuir sus archivos WSDL o XSD para todos los desarrolladores de software del cliente que se pueden utilizar para interactuar con el sistema de forma simple y rápida.

Answer 5

Ciertamente, el enfoque cenaseis escrito será más fácil desde la perspectiva del usuario final-desarrollador que es lo que prefiero. Sin embargo, si en última instancia, todo se convierte a XML detrás de las escenas o usted es inseguro wich se acercan a sus clientes van a tener, sin duda recomendaría usted apoya ambos.