Лучшие практики использования XML и XSD для сопоставления с базой данных

Question

У нас есть веб-служба ReST, которая использует POST - для вставки данных в базу данных (unmarshall data from XML) и GET для извлечения данных (marshalled в XML).

XSD используется для генерации объектов Java (с помощью JAXB-компилятора Sun) для маршалирования / демаршаллинга данных в базу данных и из нее. Мы вроде заморозили XSD как есть, потому что мы думали, что это идеально моделирует данные - и это так, но только для публикации данных на самом деле.

Теперь, когда приходит время GET данных из базы данных, мне приходится «ломать» наш текущий XSD и разрешать ему публиковать первичные ключи и другие значения данных, которые не обрабатываются запросами POST-типа. не волнуйтесь, они излишни.

Итак, теперь XSD имеет дополнительные элементы (т.е. те, которые используются только для запросов GET). Это может привести к путанице, когда вам придется объяснять третьим сторонам, которые хотят использовать ваш веб-сервис, и у вас есть этот XSD, который имеет своего рода раздвоение личности между получением и публикацией данных. Он также не выглядит чистым и элегантным, как раньше.

Что мне делать? Можно ли в вашем XSD иметь элементы, которые используются только в определенных обстоятельствах (например, для получения данных)? Или я должен иметь 2 XSD - еще один подробный, предназначенный для запросов GET, и один уменьшенный, исключительно для запроса POST ??

Ваша помощь и совет - высоко ценится.

Answer 1

Наличие полей, которые используются только в некоторых контекстах, нормально в документах XML, если вы правильно их документируете. UDDI (да, я знаю, совершенно не REST и не крутой пример) делает именно это. Когда вы «сохраняете» или «обновляете» запись в UDDI, аналогичную вашим POST и PUT, вам необходимо предоставить уникальный идентификатор в опубликованных данных, чтобы сервер знал, что с ним делать. Преимущество здесь состоит в том, что у вас есть один элемент схемы и одна результирующая структура данных, с которыми нужно работать для большинства операций над этой структурой данных (для CRU, но не всегда для D в UDDI). Поскольку вы являетесь RESTful и можете представлять уникальный идентификатор в URL-адресе ресурса, такой подход может иметь меньше смысла для вашего приложения. Одна вещь, чтобы рассмотреть, если полученные данные должны быть переданы после поиска. Если данные должны быть самодостаточными и передаваться внутри или между различными контекстами ваших клиентов, то включение идентификатора, вероятно, полезно для пользователей вашей службы, поскольку им не придется иметь дело с двумя частями данных (фактическим данные и его уникальный идентификатор). При этом ваши клиенты могут полностью абстрагироваться от взаимодействия REST / XML, и в этом случае их абстракция, вероятно, уже обрабатывает идентификатор и оставшиеся поля структуры данных.

Answer 2

Я был в подобной ситуации и создал представление, которое я использовал для своих целей "чтения". Затем я сопоставил представление с тем же XSD, что и мои основные таблицы, чтобы я мог управлять всем этим в одном месте. Это дало мне гибкость «более слабого» чтения, не беспокоясь о повреждении моего основного расположения данных.