2010-10-01 4 views
6

Мы разрабатываем приложение для iPhone, которое перезвонит службе RESTful, работающей в Tomcat. Нам нужно отправить много параметров запроса и превысить максимально допустимый номер телефона.Вызов службы RESTful с * многими * параметрами

Было бы RESTful использовать PUT-вызов с параметрами в теле, хотя намерение не изменять сервер? POST не кажется правильным, потому что он не является идемпотентным, тогда как PUT (и, следовательно, более точно напоминает поведение или GET).

Спасибо.

+0

Это JSON или XML? – Aliostad

+4

Принципы и дух REST гораздо важнее вашего продукта. Поэтому ваш продукт не должен существовать. Mark

+3

@Mark: Отличная точка. Если вы не можете следовать духу закона, просто прекратите развитие! Почему я не подумал об этом? Я сейчас звоню своему боссу и говорю ему, что эта сумасшедшая модель данных не соответствует оригинальной реляционной модели, сформулированной Чэном, и мы должны просто прекратить работу. Отлично! –

ответ

4

Если вы хотите его RESTful, вы можете сделать это так: НАПРАВЛЯТЬ параметры на сервер (в выбранном вами месте), или вы можете отправить их и позволить серверу разместить их для вас. В любом случае, вы только что создали ресурс, который содержит необходимые параметры. Затем вы отправляете GET со ссылкой на этот конкретный ресурс. Отвечая на ваш GET, сервер поэтому знает, где получить большой набор параметров. Это будет RESTful.

Это, однако, отправка двух запросов не очень эффективна, если вы можете сделать то же самое с одним запросом. Я просто стараюсь быть прагматичным.

Рассмотрите это: PUT сообщает прокси, что они не должны кэшировать ответ, но повторная попытка (любым элементом инфраструктуры вдоль линии) определенно возможна, поскольку она является идемпотентной (как GET). Что GET дает вам PUT? Ответ можно кэшировать. Но с таким большим количеством параметров я бы предположил, что большинство запросов будут уникальными, так или иначе? Таким образом, кеширование не будет приносить много окупаемости очень часто. Поэтому использование PUT представляется прагматичным и, следовательно, правильным выбором.

+0

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

1

Это нарушает дух ОТДЫХА, но если это работает, будьте прагматичны.

+0

Есть ли способ RESTful сделать это? Я не сторонник буквы закона (или спецификации в этом случае), но хотел бы следовать стандартам, если есть способ. – Ralph

6

У вас есть три варианта, которые максимально совместимую с HTTP:

во-первых, у вас есть возможность отправки Params сжатых каким-либо образом, чтобы сформировать более короткий URL.

Во-вторых, ничего не говорится о GET, в котором говорится, что вы не можете отправить сообщение-тело в запросе, в любом Content-Type или -Length вы выберете. Не все серверы поддерживают это, но сам протокол HTTP делает.

В-третьих, вы можете отправить параметры в /queries/ ресурс, и иметь, что отвечать с 201 Created и новый URL-адрес (например, /queries/78a65g82) в заголовке Location ответ, который клиент затем вызывает GET на (неоднократно, или даже в Ranges , если это выгодно) для получения результата.

+4

Я думаю, вы можете обнаружить, что некоторые прокси не перенаправляют тело запроса GET. –

+0

Как и Darrel, вы не должны передавать GET-сообщения, они могут работать в вашей dev-настройке, но могут выходить из строя в вашей prod-настройке. Это слишком ненадежно, и маршрутизация (и вовлеченные прокси) часто не под вашим контролем. –

+0

+1 для предложения/запросов/78a65g82, это то, что мы используем. – balupton

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