Какая структура XML лучше всего подходит для универсального API?

Посоветуйте, если можете.

Я создаю API веб-службы SMS, который позволит людям отправлять SMS на нужные номера мобильных телефонов. В интерфейс будет отправлен запрос, затем мы обработаем этот запрос на основе предоставленных данных учетной записи и кредитов, доступных на их учетной записи.

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

Интерфейс А

print("<?xml version = "1.0" encoding="UTF-8" standalone="yes"?>
        <Message version="1.0">
            <ClientID>11111</ClientID>
            <PassPhrase>shjfkh</PassPhrase>
            <Request Type="sms" Refno="10" ToAddress="27732687745332">
                <Content>
                      hello world
                </Content>
            </Request>
        </Message> ");

Интерфейс Б

 print("<?xml version = "1.0" encoding="UTF-8" standalone="yes"?>
    <Message>
        <mmtag name="Version">1.0</mmtag>
        <mmtag name="ClientID">1001</mmtag>
        <mmtag name="RefNO">120</mmtag>
        <mmtag name="Encoding">base64</mmtag>
        <mmtag name="Type">SMS</mmtag>
        <mmtag name="Content">hello world</mmtag>
        <mmtag name="MSISDN">27781010102</mmtag>        
    </Message>");

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


xml api sms
person Ronald Conco    schedule 01.12.2008    source источник
comment
Поместите xml как код, чтобы мы могли увидеть его в следующий раз.   -  person dacracot    schedule 02.12.2008

Ответы (8)


arrow_upward
4
arrow_downward

Интерфейс А.

Интерфейс B — это, по сути, просто список ключей/значений, тогда как интерфейс A использует структурированную природу XML и обеспечивает смысл через структуру.

Например: ClientId — это атрибут сообщения, а не самого запроса. Это ясно из рассмотрения А, но не из Б.

person jonhy    schedule 01.12.2008

arrow_upward
2
arrow_downward

Я бы еще раз пересмотрел А...

<Message version="1.0" clientID="11111" passPhrase="shjfkh">
    <Request Type="sms" Refno="10" ToAddress="27732687745332">hello world</Request>
</Message>

Это позволяет структуре подразумевать возможность нескольких сообщений в блоке сообщений.

<Message version="1.0" clientID="11111" passPhrase="shjfkh">
    <Request Type="sms" Refno="10" ToAddress="27732687745332">hello john</Request>
    <Request Type="sms" Refno="11" ToAddress="12345678901234">hello jane</Request>
</Message>
person dacracot    schedule 01.12.2008
comment
Спасибо за то, как вы переработали интерфейс A, теперь я понимаю другие возможности. еще раз спасибо. - person Ronald Conco; 02.12.2008

arrow_upward
2
arrow_downward

Еще один момент: вам, вероятно, следует заключить фактическое сообщение в CDATA, чтобы оно было отделено от вашего XML. Как это...

<Message version="1.0" clientID="11111" passPhrase="shjfkh">
    <Request Type="sms" Refno="10" ToAddress="27732687745332"><![CDATA[hello john]]></Request>
    <Request Type="sms" Refno="11" ToAddress="12345678901234"><![CDATA[hello jane]]></Request>
</Message>

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

person dacracot    schedule 01.12.2008
comment
Если пользователь не встроит ]]. Конечно, правильно было бы избежать текста сообщения!? - person Lawrence Dol; 02.12.2008

arrow_upward
2
arrow_downward

Есть несколько вещей, которые говорят в пользу интерфейса A по сравнению с интерфейсом B:

  • легче проверить с помощью схемы/DTD (особенно если тип текстового содержимого зависит от элемента)
  • структура более четкая
  • проще искать через XPath и преобразовывать через XSLT
  • легче привязываться к классам, если вы увлекаетесь такими вещами

Конечно, вы, вероятно, можете достичь всего, что упомянуто выше, с интерфейсом B, но это будет более громоздко.

Если вам нужны произвольные метаданные, которые может заполнить клиент, вы всегда можете добавить элемент с дочерними элементами по ключу/значению в интерфейс A.

Помимо всех технических причин, я думаю, что дизайн интерфейса А гораздо более эстетичен. В интерфейсе B теги практически бесполезны, потому что они все одинаковые. Следовательно, все строки mmtag мертвым грузом.

person Torsten Marek    schedule 01.12.2008
comment
спасибо за ваш вклад и за другие отмеченные преимущества интерфейса A. - person Ronald Conco; 02.12.2008

arrow_upward
1
arrow_downward

Интерфейс А. Он короче.

person Shawn Miller    schedule 01.12.2008

arrow_upward
1
arrow_downward

Интерфейс A... Я предпочитаю атрибуты содержанию тегов.

person dacracot    schedule 01.12.2008

arrow_upward
1
arrow_downward

Я бы сказал, что второй случай труднее читать, потому что он скрывает детали реализации в атрибуте.

person EBGreen    schedule 01.12.2008

arrow_upward
1
arrow_downward

Интерфейс A, по всем причинам, изложенным другими. Но я бы предложил, чтобы ToAddress был элементом, позволяющим отправлять одно и то же сообщение нескольким ToAddress:

<Request Type="sms" Refno="10">
  <To>27732687745332</To>
  <To>1234567890</To>
  <Content>Hello world</Content>
  </Request>

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

person Lawrence Dol    schedule 02.12.2008
comment
Привет, добавление refno в качестве элемента атрибута в этом случае не будет работать, поскольку каждое SMS является уникальной транзакцией, а Refno используется для идентификации каждой уникальной транзакции. Спасибо за ваш вклад. - person Ronald Conco; 02.12.2008