2013-08-29 2 views
0

Я разработал простой API Spring MVC RESTful, и теперь я перешел на сцену, чтобы создать простой проект GWT для выполнения некоторых запросов на этот api, и, очевидно, я выбираю, что сообщение будет путем обмена сообщениями JSON.RESTful API с Spring MVC и GWT и типами наложений

При получении ответа мне придется отменить его на POJO.

Я знаю, что общий подход заключается в создании так называемых «типов перекрытий», но это выглядит как простой дубликат классов java, которые я написал в api.

Вопрос в следующем: Почему бы мне просто не создать общий api, который просто содержит общие классы для выполнения этого сортировки/разборки?

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

ответ

0

Ответ REST может потребляться любым клиентом, а не конкретным клиентом. Если я правильно понимаю ваш вопрос, вы хотите построить логику маршаллинга и unmarshalling внутри вашего REST API. В идеале это нарушает принцип Single Responsibility Principal. Возможно, вам придется изменить логику отображения, если служба изменится, поэтому вы касаетесь двух разных аспектов API, где только один компонент требует изменений.

Кроме того, REST API в идеале должен быть спроектирован так, чтобы быть агностиком клиента. Это ваше особое требование перевести их на POJO, но другой клиент может захотеть использовать его как простой простой JSON. Если вы предоставите тип наложения, ваш код будет довольно слабо связан.

+0

Спасибо за ваш быстрый ответ Ashish. Я хотел бы добавить, что я не хочу строить логику маршаллинга/unmarshalling внутри REST, я просто хочу поделиться классами. Предположим, что ответ REST представляет собой список , переведенный в JSON. Затем в моем клиенте я хочу восстановить объекты Java из него. Я не понимаю, почему это могло бы сделать мой REST не агентом, являющимся клиентом. Это клиент GWT, который будет построен соответственно – MaLLinok

0

Если ваш серверный класс (например, Player) может быть сериализован/desirialized без каких-либо проблем, вы можете отправить его на клиентскую сторону без какого-либо наложения типа/преобразования (сериализация на JSON на сервере -> транспорт -> десриализация из JSON на клиенте). На стороне клиента вы можете использовать RestyGWT, например, для архивирования автоматического процесса desirialization. Типы наложения и процесс преобразования необходимы только в том случае, если экземпляр Player не может быть сериализован (например, он поддерживается Hibernate).

1

Предполагая, что вы можете определить интерфейсы для POJO, вы можете поделиться этими интерфейсами в клиенте и на стороне сервера (общий пакет)

В стороне сервера вы должны кодировать свои реализации, которые используются для RESTful API.

На стороне клиента реализация этих интерфейсов может выполняться автоматически с помощью генераторов. Для этого вы можете использовать gwtquery databinding или gwt autobeans.

Для запроса RESTful API, вы можете использовать либо gwtquery ajax или gwt requestbuilder

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

Смежные вопросы