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

Question

Пожалуйста, сообщите, если можете.

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

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

Интерфейс A

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> ");

Интерфейс B

 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, независимо от технологии, используемой в бэкэнде. Пожалуйста, поддержите ваш ответ, если вы выберете один.

Answer 1

Интерфейс А.

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

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

Answer 2

Есть несколько вещей, которые говорят об интерфейсе A через интерфейс B:

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

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

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

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

Answer 3

Еще один момент, вам, вероятно, следует заключить настоящее сообщение в 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, вы будете защищены.

Answer 4

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

<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>

Answer 5

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

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

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

Answer 6

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

Answer 7

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

Answer 8

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