Restlet изменить входящий объект и вернуть его или вернуть новую копию?

Я пытаюсь узнать о рестлетах больше, исходя из фона мыла-RPC. Одна вещь, которую я не могу понять, как это сделать (и, возможно, невозможна), - это изменять объекты по запросам или отправлять обратно скопированную версию с изменениями.

Я пытаюсь сделать что-то вроде этого:

public interface AddressService {
    @Get
    Address addOnZipCode( Address address );
}

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

Сервер запускается нормально, но когда клиент делает вызов, на сервере нет указаний на то, что вызывается реализующий метод. Кроме того, клиент не ошибается до тех пор, пока не вернется вызов сервера - возвращаемый объект равен нулю?!?

Возможно ли то, что я пытаюсь сделать здесь, с рестлетами? Если да, какие идеи о том, что я могу делать неправильно?

Я могу опубликовать больше кода, если это необходимо.

Заранее спасибо.

РЕДАКТИРОВАНИЕ №1:

Я даже пытался упростить его, чтобы не использовать пользовательские объекты:

@Post
String execute( String message );

Я получаю следующее:

INFO: Starting the default HTTP client
Exception in thread "main" Method Not Allowed (405) - Method Not Allowed
    at org.restlet.resource.ClientResource$1.invoke(ClientResource.java:1615)
    at $Proxy5.execute(Unknown Source)

Я начинаю думать, что это невозможно, поэтому мне трудно понять, насколько это жизнеспособная альтернатива веб-сервисам SOAP + RPC.

РЕДАКТИРОВАНИЕ №2: похоже, что это возможно, основываясь на примерах из книги: "Рестлеты в действии"

public interface AccountsResource {          
    @Get("txt") 
    public String represent();               

    @Post("txt") 
    public String add(String account);       
}

РЕДАКТИРОВАНИЕ №3: оказалось, что простое нажатие кнопки "стоп" в моей консоли Eclipse не останавливало экземпляр сервера. Открытие браузера по URL-адресу сервера показало некоторые подозрительные результаты — было запущено несколько старых экземпляров сервера. После закрытия их всех я получил его для работы. В конечном итоге ответ состоял в том, чтобы использовать @Post вместо @Get1.


java restlet
person javamonkey79    schedule 26.05.2011    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Посмотри на это:

http://wiki.restlet.org/docs_2.0/13-restlet/21-restlet/318-restlet/303-restlet.html

На стороне сервера ваша реализация должна быть такой:

class AddressServerResource extends ServerResource implements AddressService {
    // implementation
}

На стороне клиента:

ClientResource cr = new ClientResource("http://your-api.com/address/123");
AddressService service = cr.wrap(AddressService.class);
// use the service transparently

Редактировать:

@Post
Address addOnZipCode( Address address );
person Finbarr    schedule 26.05.2011
comment
Это то, что я делаю сейчас. К сожалению, ни один из примеров не принимает и не возвращает значение. - person javamonkey79; 26.05.2011
comment
Ах, вы не можете передать значение в методе Get. Это то, что прямо не указано в документе, но я понял после того, как использовал Restlet в течение нескольких недель. - person Finbarr; 26.05.2011
comment
Метод HTTP Get не позволяет использовать тело запроса. Тело запроса — это то, что RESTlet использует для согласования содержимого, чтобы преобразовать его в объект Java. Вы можете передавать параметры только в методах PUT и POST. - person Finbarr; 26.05.2011
comment
Теперь я получаю ошибку 405 - кажется, вы не можете использовать аннотации и сделать это по крайней мере в соответствии с этим [manning-sandbox.com/message.jspa?messageID=106811] - person javamonkey79; 26.05.2011
comment
Или, может быть, вы можете, я не уверен, как. - person javamonkey79; 26.05.2011
comment
Если вы можете опубликовать или дать ссылку на остальную часть соответствующего кода, я посмотрю. - person Finbarr; 26.05.2011
comment
Все, что я сделал, это изменил интерфейс с @Get на @Post. - person javamonkey79; 26.05.2011
comment
Вы также добавляете аннотацию @Post к методу реализации? - person Finbarr; 26.05.2011