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

Question

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

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

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

AddNewCar( CarObject car )

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

AddNewCar( string carXml )

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

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

Если у вас есть более подробная информация, пожалуйста, дайте мне знать.Спасибо

---

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

Answer 1

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

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

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

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

Answer 2

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

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

Answer 3

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

Answer 4

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

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

Answer 5

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