JSON-схема в WADL

Поэтому я начал смотреть на то, как можно было бы присоединить
грамматику JSON-Schema к документу JSON в WADL-описании службы. Это еще не спецификация; но предложение о том, как это может работать последовательно.

Сейчас я в основном работаю с Джерси, поэтому давайте посмотрим, что Джерси в настоящее время сгенерирует для сервиса, который возвращает XML и JSON. Таким образом, сервис здесь реализован с использованием привязки JAX-B, поэтому они оба используют похожую структуру, определенную ссылкой XML-Schema в include.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<application xmlns="http://wadl.dev.java.net/2009/02">
    <doc xmlns:jersey="http://jersey.java.net/" jersey:generatedBy="Jersey: 1.16-SNAPSHOT 10/26/2012 09:28 AM"/>
    <grammars>
        <include href="xsd0.xsd">
            <doc title="Generated" xml:lang="en"/>
        </include>
    </grammars>
    <resources base="http://localhost/">
        <resource path="/root">
            <method id="hello" name="PUT">
                <request>
                    <representation xmlns:m="urn:message" element="m:requestMessage"  mediaType="application/json" />
                    <representation xmlns:m="urn:message" element="m:requestMessage" mediaType="application/xml" />
                </request>
                <response>
                    <representation xmlns:m="urn:message" element="m:responseMessage" mediaType="application/json"/>
                    <representation xmlns:m="urn:message" element="m:responseMessage" mediaType="application/xml" />
                </response>
            </method>
        </resource>
    </resources>
</application> 

Итак, первое, что мы рассмотрели, — это повторно использовать существующее свойство элемента, которое определяется как QName, в элементе представления для ссылки на импортированную JSON-схему. Это показано здесь как с другим произвольным пространством имен, так что его можно отличить от элементов XML без пространства имен.

    <grammars>
        <include href="xsd0.xsd" />
        <include href="application.wadl/responseMessage" />
    </grammars>


    <representation element="responseMessage" mediaType="application/json"/>

Or
    xmlns:json="http://wadl.dev.java.net/2009/02/json" 

    <representation 
        element="json:responseMessage" mediaType="application/json" />

Проблема в том, что спецификация JSON-Schema в ее нынешнем виде не имеет понятия свойства «name», поэтому каждая JSON-Schema уникально идентифицируется своим URI. Также из моего прочтения спецификации каждая JSON-схема содержит определение не более одного документа, а не нескольких типов / документов, которые могут содержаться в XML-схеме.

Поэтому следующим лучшим предложением было бы просто использовать часть URI «имя файла» в качестве прокси для URI; но, конечно, это не обязательно будет уникальным. Я мог видеть, например, что правительство США и Yahoo опубликовали там свой собственный «адресный» микроформат.

Лучшее решение этой проблемы — ввести новый атрибут, к счастью, с учетом этого была разработана спецификация WADL, которая является типом URI, который можно использовать для прямой ссылки на определения JSON-схемы. Поэтому вместо прямого импорта в предыдущем примере мы имеем свойство URI для самого элемента. Имя атрибута »
byedby «получено из предложения JSON-Schema и соответствует значению rel, используемому для ссылок на атомы в спецификации.

xmlns:json="http://wadl.dev.java.net/2009/02/json-schema" 
    xmlns:m="urn:message" 


    <grammars>
        <include href="xsd0.xsd" />
    </grammars>

    <representation 
        mediaType="application/json"
        element="m:responseMessage" 
        json:describedBy="application.wadl/responseMessage" />

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

Если у вас есть определение JSON-схемы, то некоторые пользователи захотят покончить с XML все вместе, поэтому, наконец, вот простое сопоставление WADL с документом JSON, который содержит только информацию о JSON-схеме. Сергей Бреёзкин предположил, что отображение JSON покажет только грамматику json, и я подхожу к
такому мышлению. Мне было бы интересно услышать о сценарии использования для отображения JSON, который хотел бы получить доступ к XML-схеме.

{
   "doc":{
      "@generatedBy":"Jersey: 1.16-SNAPSHOT 10/26/2012 09:28 AM"
   },
   "resources":{
      "@base":"http://localhost/",
      "resource":{
         "@path":"/root",
         "method":{
            "@id":"hello",
            "@name":"PUT",
            "request":{
               "representation":[
                  {
                     "@mediaType":"application/json",
                     "@describedby":"application.wadl/requestMessage"
                  }
               ]
            },
            "response":{
               "representation":[
                  {
                     "@mediaType":"application/json",
                     "@describedby":"application.wadl/responseMessage"
                  }
               ]
            }
         }
      }
   }
}

В настоящее время я использую mime-тип «application / vnd.sun.wadl + json» для того, чтобы это сопоставление соответствовало стандартному MIM-типу WADL. Я подозреваю, что мы хотели бы изменить это в будущем; но это подойдет для начала.

Так что это все очень интересно, но вы не можете поиграть с этим, если у вас нет примера реализации. У меня есть кое-что, работающее как для серверной части, так и для генератора Java-клиентов в Джерси и wadl2java соответственно, и это будет темой моего следующего поста. Я работал с
Павлом Бучеком и командой из Джерси над этими реализациями и предложением WADL. Большое ему спасибо за то, что терпели меня.