Дизайн API: выставить XML или объекты

Question

Мы запускаем новый сервис среднего уровня, который позволит внутренним клиентским системам создавать, обновлять и запрашивать записи в некоторых базовых хранилищах данных. Служба будет объединять до 3 отдельных баз данных. Для целей этого вопроса предположим:

Хранилище данных № 1: Собственная база данных XML.
Хранилище данных № 2: готовая реляционная база данных.
Хранилище данных № 3: Хранилище плоских файлов (файлы хранятся в двоичном виде). ​​

Клиенты не будут знать (и не будут заботиться) о том, какое хранилище данных они запрашивают / обновляют. Новая служба примет это решение. У меня такой вопрос: должен ли мой API предоставлять XML или объекты? Например. Новый API будет иметь метод add. Если предположить, что наша система является системой хранения автомобилей, то метод add API может выглядеть следующим образом:

AddNewCar( CarObject car )

или, это может выглядеть так:

AddNewCar( string carXml )

Теперь, даже несмотря на то, что 2-й метод слабо типизирован при входе, XML-файл сразу же будет проверен по схеме как минимум.

Новый сервис будет написан на C # (еще не определено, какая версия, но, вероятно, 3 / 3.5 с WCF). Клиентами API могут быть C # / VBA / VB.Net / C ++ / Java).

Если хотите узнать больше, дайте мне знать. Спасибо

---

Обновление: обратите внимание, что API также будет публиковать XML по шине сообщений. Например. Когда будет добавлен новый автомобиль, будет опубликован XML-код автомобиля, так что каждый, кто интересуется новыми автомобилями, получит уведомление.

Answer 1

Вы не должны раскрывать XML, так как это фиксирует ваш формат и любые будущие решения, которые могут возникнуть в отношении инфраструктуры. Я всегда буду идти строго типизированным путем, чтобы гарантировать, что вы правильно абстрагируете свою реализацию от использования.

Если вы возьмете XML-маршрут и обнаружите, что в процессе разработки XML-то по какой-то причине придется изменить, вам будет намного сложнее изменить все виды использования вашего API для решения этой проблемы, чем если бы вы строго набрали API и скрыл детали XML за объектами.

Answer 2

Я бы сказал, выставить объект API. Хотя и не по причинам, упомянутым в другом посте выше, - разоблачение XML, приводящее к фиксированному формату, который труднее изменить.

Можно утверждать, что API бизнес-объектов со строгой типизацией так же сложно изменить, как и XML - и то, и другое потребует повторной компиляции и повторной сборки. Так что это не причина, почему вы должны отказаться от XML.

Причина - ИМНШО - это уровень абстракции. На уровне API вы говорите о том, какие бизнес-объекты или службы могут выполнять какие действия с другими бизнес-объектами. Поэтому API должен говорить в терминах бизнес-объектов.

Как уже упоминалось в другом посте, вы всегда можете поддержать бизнес-объекты XML-представлениями. Сохранение XML-представлений ваших бизнес-объектов и сервисов на более низком уровне абстракции, чтобы ваш API предоставил вам всю гибкость XML, в то же время позволяя создавать API более высокого уровня с хорошей семантикой.

Answer 3

Вы должны создать API с использованием Objects, а затем создать интерфейс веб-службы вокруг этого API (например, для Java вы должны использовать java2wsdl в вашем интерфейсе, а затем wsdl2java для создания каркасной реализации на стороне сервера или реализации на стороне клиента Я уверен, что в WCF существует эквивалентная методология), которую могут запрашивать все другие системы.

Поскольку у вас многоязычные клиенты, я думаю, что веб-служба - ваш лучший выбор, и (игнорируя реализацию бизнес-логики) всего лишь несколько минут работы над вашим API. Вы можете распространять файлы wsdl или xsd среди всех разработчиков клиентского программного обеспечения, которые они затем могут использовать для простого и быстрого взаимодействия с вашей системой.

Answer 4

Вы должны создать API с использованием объектов и использовать WCF для предоставления XML API, если это необходимо.

Answer 5

Конечно, строго типизированный подход будет проще с точки зрения конечного пользователя-разработчика, что я бы предпочел. Однако, если в конечном итоге все закулисно преобразуется в Xml или вы не уверены в том, какой подход будут использовать ваши клиенты, я определенно рекомендую вам поддерживать оба варианта.