нужен совет о том, как передавать сгруппированные параметры через QUERY_STRING в приложении REST - PullRequest
Новая
       4

нужен совет о том, как передавать сгруппированные параметры через QUERY_STRING в приложении REST

0 голосов
/ 02 декабря 2011

Мое бэкэнд-приложение принимает, скажем, три параметра для создания объекта и возвращает его как JSON 

http://server/app/resource.json?a=foo&b=3&c=bar

У меня есть другая возможность в моем приложении, которая может взять объект, возвращенный из указанного выше URI, и "преобразовать""это в другой объект.Сейчас я делаю следующее: 

http://server/app/resource.json?a=foo&b=3&c=frob&transform_to=blarg

Это не кажется мне интуитивно понятным.Мне интересно, смогу ли я сделать что-то вроде 

http://server/app/resource.json?in={a:foo,b:3,c:frob}&out={c:blarg}

Буду признателен за любой совет по этому поводу.

Еще более интересно было бы, если бы я мог взять вывод из одного URI и передать его каквход в другой URI, но я предполагаю, что нам предстоит пройти долгий путь.

1 Ответ

2 голосов
/ 02 декабря 2011

Говоря в терминах REST, то, что вы делаете, совершенно неправильно по нескольким причинам.

У меня есть другая возможность в моем приложении, которая может взять объект, возвращенный из вышеуказанного URI, и "преобразовать" его в другой объект.

Вы можете иметь несколько представлений одного ресурса, хотя «преобразование» его в другой объект уже означает, что вы говорите о другом ресурсе.

Чтобы решить эту проблему, по крайней мере, вам нужно создать другой ресурс, который будет производить другой объект. Например: http://server/app/brag.json?a=foo&b=3&c=bar

http://server/app/resource.json?a=foo&b=3&c=frob&transform_to=blarg

Вы кодируете действие (то есть transform_to) непосредственно в URL. Это не ОТДЫХ, это очень обычный RPC. Вы должны зависеть от единого интерфейса и использовать только методы GET / POST / PUT / DELETE (глаголы) в случае HTTP.

Опять же, создание другого ресурса, т.е. /blarg.json, который принимает параметры запроса, будет намного чище, и вы избежите передачи действий в URL.

http://server/app/resource.json?in={a:foo,b:3,c:frob}&out={c:blarg}

параметр такого типа "{a: foo, b: 3, c: frob}" не имеет особого смысла. Если ваша бэкэнд-система знает, от каких параметров она зависит, почему бы не остаться с этим более чистым и далеко естественным подходом? "? А = Foo & Ь = 3 & с = бар"

В этом примере преобразование "& out = {c: blarg}" в "& format = blarg" частично устранит проблему действия, упомянутую выше, хотя это все еще означает, что ваш ресурс имеет два варианта (не представления) одного типа носителя (приложения / JSON в этом случае). Это логически приводит нас к созданию другого ресурса, а не к преобразованию существующего в другой объект.

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

Да, это абсолютно законно, но это зависит от того, как вы будете реализовывать такое поведение.

=============================================== ============================================

При работе с веб-службами RESTful, основанными на протоколе HTTP, основная цель - полагаться на семантику HTTP и всегда избегать создания дополнительных правил поверх нее. Веб-сервисы SOAP являются хорошим примером этого (это не значит, что SOAP - это кровать и т. Д.). SOAP всегда использует HTTP-метод POST для связи с сервером и кодирует все параметры и действия в XML.

...