Home/ Questions/Q 90159
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-10T22:49:47+00:00

We’re embarking on a new middle tier service that will allow internal client systems

  • 0

We’re embarking on a new middle tier service that will allow internal client systems to create and update and query records in some underlying data stores. The service will aggregate as many as 3 seperate underlying datastores. For the purposes of this question assume:

Data store #1: Proprietary XML Database.
Data store #2: Off the shelf relational Database.
Data store #3: Flat file store (files stored as binary).

The clients will not know (nor care) which datastore they are querying/udpating. The new service will make that decision. My question is this: Should my API expose XML or objects? E.g. The new API will have an add method. Assuming that our system is a car storage system, then the add method of the API may look like this:

AddNewCar( CarObject car )

or, it could look like this:

AddNewCar( string carXml )

Now, even though the 2nd method is weakly typed at entry, the XML will immediately be validated against schema as a minimum.

The new service is going to be written in C# (not decided yet on which version, but probably 3/3.5 with WCF). Clients of the API could be C#/VBA/VB.Net/C++/Java).

Any more details please let me know. Thanks

Update: Note that the API will also be publishing XML over a message bus. E.g. when a new car is added the car XML will be published so that anyone who is interested in new cars will be notified.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. I’d say expose an object API. Although not for the reasons mentioned in another post above – that of exposing XML resulting in a fixed format that is more difficult to change.

    Arguably, an API of strongly-typed business objects is as difficult to change as XML – both will require re-compilation and re-building. So that isn’t the reason why you should discard XML.

    The reason – IMNSHO – is that of level of abstraction. At the API level, you are talking in terms of what business objects or services can perform what actions on what other business objects. Therefore, the API must talk in terms of business objects.

    As mentioned in another post here already, you can always back the business objects with XML representations. Keeping the XML representations of your business objects and services at a lower level of abstraction that your API will provide you all the flexibility of XML while at the same time allowing you to build a higher level API that has good semantics.

    • 0