Добавление полей в веб-сервис - PullRequest
3 голосов
/ 03 февраля 2009

У меня есть сервис SOAP, который предоставляет метод

TradeDetail getTradeDetail()

TradeDetail хранит 5 полей, номер транзакции, даты и т. Д.

Мне нужно добавить пару полей в TradeDetail. Я хочу сохранить обратную совместимость (на некоторое время), и похоже, что мои возможности ограничены созданием нового класса с дополнительными полями

TradeDetail2 getTradeDetail2()

Теперь это будет работать - я делал это раньше. Но есть ли другие решения, которые люди использовали?

1011 * Е.Г. *

  • Принципиально измените TradeDetail2, добавив пары имя-значение.
  • Унаследовать TradeDetail2 от TradeDetail, это уменьшит код, но увеличит связь
  • Вместо XML вернуть JSON

Я смогу довольно быстро удалить оригинальный интерфейс, так что код будет очищен, а дополнительный TradeDetail2 не будет длиться вечно!

спасибо

Ответы [ 3 ]

3 голосов
/ 03 февраля 2009

Именно поэтому я предпочитаю иметь полный контроль над отображением XML на объект, чтобы я мог отделить модель от интерфейса XML. В вашем случае я просто добавил бы новые поля в TradeDetail и посчитал бы их «необязательными» для обратной совместимости. Это будет пример XML-> Object mapping для TradeDetail в среде, используемой моей командой, написанной для вашего интерфейса:

// this would go into my client endpoint class
public TradeDetail getTradeDetail() {
  Element requestRoot = new Element("GetTradeDetail");
  Element responseRoot = invokeWebServiceAndReturnJdomElement(requestRoot);
  return mapTradeDetail(responseRoot);
}

// this would go into my client XO mapping class
public TradeDetail mapTradeDetail(Element root) {
  TradeDetail tradeDetail = new TradeDetail();
  tradeDetail.setField1 = fetchString(root, "/GetTradeDetail/Field1");
  tradeDetail.setField2 = fetchInteger(root, "/GetTradeDetail/Field2");
  tradeDetail.setField3 = mapField3(root, "/GetTradeDetail/Field3");
  tradeDetail.setField4 = fetchString(root, "/GetTradeDetail/Field4");
}

Этот тип клиента будет игнорировать новые поля, поэтому будет совместим с новой версией протокола, пока я не добавлю что-то подобное в конец этого же метода в версии 2:

if (fetchXPath(root, "/GetTradeDetail/Field5") != null) {
  // so we're talking with server which speaks new version of protocol
  tradeDetail.setField5 = fetchString(root, "/GetTradeDetail/Field5");
}

Сервер будет работать с аналогичным кодом, возможно, проверяя версию клиента и отображая дополнительные поля, только если клиент поддерживает новую версию протокола.

На мой взгляд, клиент должен быть написан так, чтобы несколько дополнительных полей, добавленных к протоколу, не сломали клиента - я не могу позволить себе потерять его просто потому, что вышестоящий провайдер добавил новые функции и не сообщил мне о Это. Если поставщик изменяет существующие обязательные поля, конечно, клиент нуждается в модификации. Вот почему вышестоящий провайдер должен версия протокола и поддерживать старую версию в течение как минимум нескольких месяцев.

3 голосов
/ 03 февраля 2009

Я сочувствую - некоторые из моих веб-сервисов пронизаны myMethod(), myMethod2(), myMethod3() и т. Д. Просто потому, что мне нужно было добавить несколько новых полей.

Имеет ли смысл сохранять имя метода и вместо этого создавать новую конечную точку для каждой версии вашего API? например:

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

Любые приложения, использующие ваш веб-сервис, вероятно, в любом случае должны были бы быть переписаны и / или перестроены под новый WSDL, чтобы воспользоваться новыми полями, так почему бы просто не переписать / перестроить их под новый API v1.1.

Я считаю, что это также помогает при общении с владельцами / разработчиками приложений, использующими ваш сервис - например, " Версия [старая] нашего API веб-сервиса больше не будет поддерживаться после [дата], пожалуйста, убедитесь, что вы используете хотя бы версию [новую]."

1 голос
/ 03 февраля 2009
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...