Как лучше всего реализовать отношения ссылок для HATEOAS в XML? - PullRequest
5 голосов
/ 16 января 2012

У нас есть веб-приложение на Java-сервере, в котором ядро ​​системы содержит очень сложную модель предметной области, разработанную в соответствии с принципами доменного проектирования.По большей части эти доменные объекты были очень мало затронуты другими приложениями.

Сейчас мы стремимся разместить API веб-сервисов REST перед системой, и я борюсь с тем, как наилучшим образом реализовать ссылки HATEOAS, которые входят в наш собственный новый тип носителя.Например, предположим, у нас есть класс домена foo, который имеет свойства id и name с аннотациями JAX-B:

@XmlType(name = "foo")
public class FooImpl implements Foo {

    private String name;
    private String id;

    ...snip....

@XmlID
@XmlAttribute
@Override
public String getId() {
    return id;
}

    @XmlElement
    @Override
    public String getName() {
        return name;
    }

    @Override
    public void setName(final String name) {
        this.name = name;
    }
}

Но XML-код, который я хочу вернуть, выглядит следующим образом:

<foo id="123" href="http://myserver.com/foos/123">
   <name>myFoo</name>
   <links>
          <link rel="previous" href="http://myserver.com/foos/122" type="application/mything+xml" />
          <link rel="next" href="http://myserver.com/foos/124" type="application/mything+xml" />
          <link rel="edit" href="http://myserver.com/foos/123" type="application/mything+xml" />
          <link rel="revise" href="http://myserver.com/foos/123" method="put" type="application/mything+xml" />
          <link rel="cancel" href="http://myserver.com/foos/123?op="cancel"" method="post" type="application/mything+xml" />
   </links>
</foo>

Каков наилучший способ сделать это так, чтобы я не загрязнял дизайн моего домена этими ссылками на типы носителей, но все же мог использовать мощь JAX-B для сортировки XML?Вот некоторые мысли:

1) Адаптеры JAX-B - могу ли я использовать их для изменения XML для сущностей и вставки ссылок ... это возможно?это разумно?Есть примеры?

2) Уровень DTO - Создать новый уровень службы REST, который преобразует мои доменные объекты в DTO.До сих пор нам удавалось избегать хлопот DTO.Хотя это обеспечило бы полную гибкость в том, что мы возвращаем клиенту, я также не собираюсь создавать здесь независимых от домена клиентов.

3) Заголовки ссылок - мне очень нравится эта идея, ноЯ не думаю, что это сработает (само по себе), потому что иногда наши ресурсы содержат коллекции подресурсов.В этом случае подресурсы все равно должны быть упорядочены в XML, содержащий ссылки / ссылки и т. Д. Таким образом, хотя заголовки ссылок решают проблему для типа верхнего уровня, она не решает всей проблемы.Не стесняйтесь говорить иначе!

Есть ли другой подход, который поможет мне избежать DTO и при этом оставаться прозрачным для модели предметной области?

Ответы [ 2 ]

2 голосов
/ 10 февраля 2012

Проблема в том, что для правильной генерации ссылок требуется знание контекста, в котором они генерируются, что, в свою очередь, означает, что простые перехватчики JAXB не будут выполнять свою работу: они просто не будут знать, какой URL вставлять.Более того, генерация следующей и предыдущей ссылок потребует знания этих значений;вероятно, небезопасно говорить, что они являются последовательными, так как это будет означать, что ресурс изменяет свой URL при удалении какого-либо другого ресурса, что было бы безумием.

Самый безопасный и простой способ - это класс-оболочка(с аннотациями сериализации JAXB на нем), который делегирует уровню DAO для информации, в которой он нуждается.Хотя это может быть достаточно много кода для написания, по крайней мере, легко получить такой код правильно.Придумать автоматизированное оформление будет намного сложнее.

0 голосов
/ 26 февраля 2012

RESTEasy поддерживает ссылки через атом или заголовок. Есть несколько дополнительных аннотаций, с помощью которых вы можете указать связанные сервисы. См. Главу 8 документации RESTEasy.

...