Еще больше вопросов о RESTful URI - PullRequest
3 голосов
/ 20 февраля 2011

Числовые идентификаторы и имена

Например, какой из них вы бы выбрали для идентификации одной транзакции с одного банковского счета для одной компании:

  1. / компании / freds-painting-ltd / счета / сбережения / транзакции / 4831
  2. / компании / freds-painting-ltd / счета / 1 / транзакции / 4831
  3. /компании / 62362 / счета / 1 / транзакции / 4831
  4. Вы идиот, что-то совершенно другое!Крики, ты даже ЧИТАЛ диссертацию Филдинга?

Теперь, я думаю, 1-й является наиболее читабельным.Если у меня несколько компаний или я, например, бухгалтер, управляющий несколькими компаниями, сразу становится понятно, на какую компанию и какую учетную запись я смотрю.Это также более доступное для закладки / отправки по электронной почте и предотвратит «ловлю» других компаний путем изменения идентификатора компании.Я хотел бы, чтобы идентификаторы транзакций были уникальными для учетной записи (т. Е. Как «сберегательные», так и «текущие» счета могли иметь транзакцию «1»

«Компания» будет моим «на высшем уровне» или «первым»).class 'resource. Совсем ничего не будет разделено между компаниями. Таким образом, он будет идеальным кандидатом на осколок (или "предок" / "пространство имен" на языке Google App Engine). Так что мне остается только волноватьсяо том, что имена учетных записей уникальны в одной компании. Каждая компания может иметь учетную запись, называемую «сбережения».

Не уверен, какова ситуация в остальном мире, хотя LTD или PLCв Великобритании будет иметь уникальное имя, может быть много предприятий, занимающихся «мытьем окон» Дейва (так называемое торговое название).

Владелец (-ы) бизнеса могут потенциально выбрать на верхний уровень / компанию / компаниюУкажите имя URI, которое будет общедоступным, и будет содержать некоторые основные сведения, такие как веб-сайт, контактные данные и т. д., но все нижеприведенное НИКОГДА не будет доступно для поисковых систем.

Так чтоу вас есть следующие мысли / проблемы:

1) Разумно ли, когда кто-то входит в систему, чтобы добавить свою компанию, сказать: «Извините, занято дело« Мойка окон Дэйва »».Как насчет «Dave's Window Cleaning Portsmouth» (заняв свое место в другом поле)?Меня беспокоит то, что для более известной компании вы отказываетесь от того, что у них есть учетная запись с вами.Или чтобы кто-то мог использовать эту форму для поиска имен.Возможно, не важная персона.

2) Размер названия компании.Было бы разумно для такого названия, как «Мойка окон Дейва, садоводство и множество других вещей»?Таким образом, создавая URL-адрес, такой как «daves-window-cleaning-gardening-and-load-of-other-stuff /»

3) Как иметь дело с кем-то, меняющим свое фирменное наименование - я бы подошел к этому, создавновая компания с этим идентификатором строки, копируя все, затем удаляя старый ресурс.Исходный URI будет возвращать 404, а не перенаправлять - так как вы не можете гарантировать, что кто-то другой не захочет использовать теперь неиспользуемое имя, или даже если в прошлом несколько человек использовали одно и то же имя.

4) Должен ли «реальный» уникальный идентификатор быть числом в бэкэнде, и для каждого запроса, который нужно обработать, сначала сделайте запрос на то, к какому идентификатору компании относится это имя.

5) Воздействиепоиска транзакции в слое постоянства.

6) Возможность перезаписи URL, но тогда это не сработает в GAE и не решит проблему обеспечения уникальности названий компаний.

Веб-сервис RESTful против веб-сайта RESTful

Итак, у нас потенциально есть этот прекрасный веб-сервис RESTful, который может использовать последнее шикарное приложение для iphone / android (мания величия).Но как насчет основного сайта?Я отмечаю, что прямо сейчас URL, который я вижу в верхней части моей страницы, не является «RESTful»: / questions / ask - это действие.На сервере нет ресурса Ask.Это больше состояние страницы, подготовка к POSTing в / questions / - или, если я редактирую, PUTing в / questions / {id}

Я также отмечаю, что Stackoverflow имеет такие URI, как / questions / 362352 / name-of-the-question, и что последняя часть может быть пропущена, и одна из них будет перенаправлена ​​на нее.

Должен ли я разместить совершенно отдельное веб-приложение, которое использует мой прекрасный веб-сервис (из того же домена)? Нужен ли мне отдельный сервер REST или я могу полагаться на согласование содержимого (JSON / XML) и HTTP-глагол, чтобы выбрать правильный метод (я использую Джерси) и вернуть правильное представление?

Таким образом, я мог бы / companies / aboxo / вернуть всю HTML-страницу (используя stringtemplate.org), если это GET / , text / plain или test / html и JSON / XML для других?

Но что происходит с транзакцией «добавить / изменить / удалить»? Будет ли GET / / companies / freds-painting-ltd / Saving / Transactions /? Template = add быть в порядке (или GET ../transactions/352?template=edit), и это вернет правильный HTML

Размышление об этой последней детали почему-то сводит меня с ума.

Комментарии, предложения, откровенные насмешки - все приветствуются!

Marcos

Ответы [ 2 ]

0 голосов
/ 29 ноября 2012

Для канонического URI я предлагаю просто /transactions/{id}, так как я предполагаю, что транзакция знает, что такое компания и учетная запись.Следовательно, # 4: -)

Является ли SEO проблемой?Я полагаю, вы не хотите, чтобы случайные люди выходили из интернета, ища деньги для транзакций компании X ?!Поэтому я бы просто держал имена (которые могут измениться) вне URI.

0 голосов
/ 31 марта 2011

Rails решает проблему "id vs name", отображая оба в URL, но используя только id для фактической идентификации, например:

/companies/62362-freds-painting-ltd/accounts/1-savings/transactions/4831

то есть - для тех, у кого есть "симпатичный URL", функция, которая генерирует ваш путь, напишите и идентификатор, и имя ... но для вашего маршрутизатора, где это уместно: вы удаляете все, что не является идентификатором.

Между прочим, это означает, что ваш клиент может написать что угодно в URL, и это не будет иметь значения:

/companies/62362-i_luv_blue_turtles/accounts/1-your_mum/transactions/4831

и ваш роутер все еще видит:

/companies/62362/accounts/1/transactions/4831

:)

...