Как Вы удаляете границу Компонента Flex 4 TextArea (зажгите тематический ореол),

Шаг назад

Прежде всего, REST описывает URI как универсально уникальный идентификатор. Слишком много людей увязло в структуре URI и какие URI "более спокойны", чем другие. Этот аргумент так же нелеп, как если бы сказать, что называть кого-то «Бобом» лучше, чем называть его «Джо», - оба имени выполняют «идентификацию человека». URI - это не что иное, как универсально уникальное имя.

Так что в глазах REST спорить о том, является ли ?id=["101404","7267261"] более спокойным, чем ?id=101404,7267261 или \Product\101404,7267261, несколько бесполезно.

Теперь, сказав, что много раз, как создаются URI, обычно могут служить хорошим индикатором для других проблем в RESTful-сервисе. В ваших URI есть пара красных флажков и вопрос в целом.

Предложения

1. Множество URI для одного и того же ресурса и Content-Location

   Мы можем принять оба стиля, но эта гибкость на самом деле вызывает больше путаницы и головные боли (ремонтопригодность, документация и т. д.)?

   URI идентифицируют ресурсы. Каждый ресурс должен иметь один канонический URI. Это не означает, что вы не можете иметь два URI, указывающих на один и тот же ресурс , но есть хорошо определенные способы сделать это. Если вы решите использовать форматы JSON и списки (или любой другой формат), вам необходимо решить, какой из этих форматов является основным каноническим URI. Все ответы на другие URI, которые указывают на один и тот же «ресурс», должны включать заголовок Content-Location .

   Придерживаясь аналогии с именем, наличие нескольких URI похоже на использование псевдонимов для людей. Это вполне приемлемо и часто очень удобно, однако, если я использую псевдоним, я все еще, вероятно, хочу знать его полное имя - «официальный» способ обращения к этому человеку. Таким образом, когда кто-то упоминает кого-то по имени, «Nichloas Telsa», я знаю, что он говорит о том же человеке, которого я называю «Ник».

2. «Поиск» в вашем URI

   Более сложный случай, когда мы хотим предложить более сложные входные данные. Например, если мы хотим разрешить несколько фильтров для поиска ...

   Мое общее правило: если ваш URI содержит глагол, это может указывать на то, что что-то не так. URI идентифицируют ресурс, однако они не должны указывать , что мы делаем с этим ресурсом. Это работа HTTP или, если можно так выразиться, нашего «единого интерфейса».

   Чтобы победить аналогию с именем, использование глагола в URI похоже на изменение чьего-либо имени, когда вы хотите с ним взаимодействовать. Если я общаюсь с Бобом, имя Боба не становится «BobHi», когда я хочу сказать ему «Привет». Точно так же, когда мы хотим «искать» продукты, наша структура URI не должна изменяться с «/ Product / ...» на «/Search/...".

Ответ на ваш первоначальный вопрос

1. Относительно ["101404","7267261"] против 101404,7267261: я предлагаю здесь избегать синтаксиса JSON для простоты (т.е. не требовать вашего пользователи делают кодировку URL, когда вам это не нужно). Это сделает ваш API более удобным. Еще лучше, как рекомендовали другие, использовать стандартный формат application/x-www-form-urlencoded, так как он, вероятно, будет наиболее знаком вашим конечным пользователям (например, ?id[]=101404&id[]=7267261). Это не может быть "довольно", но Pretty URIs не обязательно означают Используемые URI. Однако, чтобы повторить мою начальную точку, хотя, в конечном счете, когда речь идет о REST, это не имеет значения. Не зацикливайтесь на этом.

2. Ваш пример URI сложного поиска может быть решен почти так же, как и пример вашего продукта. Я бы порекомендовал снова перейти на формат application/x-www-form-urlencoded, так как это уже стандарт, с которым многие знакомы. Кроме того, я бы порекомендовал объединить два.

Ваш URI ...

/Search?term=pumas&filters={"productType":["Clothing","Bags"],"color":["Black","Red"]}    

Ваш URI после кодирования URI ...

/Search?term=pumas&filters=%7B%22productType%22%3A%5B%22Clothing%22%2C%22Bags%22%5D%2C%22color%22%3A%5B%22Black%22%2C%22Red%22%5D%7D

Может быть преобразовано в ...

/Product?term=pumas&productType[]=Clothing&productType[]=Bags&color[]=Black&color[]=Red

Помимо того, что нужно избегать требования кодирования URL и делать вещи более стандартными, теперь он немного гомогенизирует API. Пользователь знает, что если он хочет получить продукт или список продуктов (оба они рассматриваются как один «ресурс» в терминах RESTful), они заинтересованы в /Product/... URI.