Для доступа к моему сайту третьим лицам необходимо получить совет по URL REST - PullRequest
2 голосов
/ 30 января 2009

Внимание! На самом деле этот вопрос не является вопросом ASP.NET. На него может ответить любой, кто знает что-либо об URLS. Я просто использую маршрутизацию ASP.NET, поэтому включил эту деталь.

В двух словах, мой вопрос:

«Какой формат URL я должен разработать, чтобы я мог предоставить его внешним сторонам, чтобы попасть в определенное место на моем сайте, которое будет перспективным. [Я новичок в создании этих« REST »URL]».


Мне нужен URL-адрес маршрутизации ASP.NET, который будет передан третьей стороне для отслеживания маркетинговых кампаний. По сути, это «шлюз» URL, который перенаправляет пользователя на определенную страницу нашего сайта, которая может быть домашней страницей, специальным конкурсом или конкретным продуктом.

В дополнение к , пытающемуся захватить реферера Мне потребуется получить partnerId, номер кампании и, возможно, другие параметры. Я хочу предоставить маршрут для этого, НО я хочу сделать это правильно с первого раза, потому что, очевидно, я не могу легко изменить его, когда он используется снаружи.

Как выглядит нечто подобное?

routes.MapRoute(
   "3rd-party-campaign-route",
   "campaign/{destination}/{partnerid}/{campaignid}/{custom}",
   new
   {
       controller = "Campaign",
       action = "Redirect",
       custom = (string)null // optional so we need to set it null 
   }
); 

кампания : возможно, вам не нужно слово «кампания» в фактической ссылке - поскольку пользователи увидят его в строке URL-адреса. я мог бы изменить это на что-то загадочное, как 'c'.

destination : определяет, на какую страницу нашего сайта будет переходить пользователь. Например, PR, чтобы направить пользователя на страницу товаров.

partnerid : идентификатор нашей компании, например SO для переполнения стека.

campaignid : идентификатор кампании, например 123 - уникальный для каждого партнера. Я понял, что думаю, что предпочел бы, чтобы сторонние компании могли сами управлять идентификаторами кампаний, а не предоставляли веб-сайт для «создания кампании». я не полностью уверен в этом еще, хотя.

custom : пользовательские данные (необязательно). я могу добавить дополнительные параметры пользовательских данных, не нарушая существующие URL-адреса

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

Кроме того, мы хотим знать, возможно, какое изображение они использовали для связи с нами (чтобы мы могли отследить, какой баннер работает лучше всего). Я ДУМАЮ, что это кандидат на новую кампанию, в отличие от настраиваемого поля данных, но я не уверен.

В настоящее время я использую очень примитивный URL, такой как http://example.com? Cid = 123 . В этом случае идентификатор кампании необходимо выдать третьей стороне, и это просто не очень гибкая система. Я хочу немедленно перейти на новую систему для новых клиентов.

Есть какие-нибудь мысли о проверке будущего этой системы? Что я мог пропустить? Я знаю, что всегда могу добавить новые форматы, но я хочу максимально использовать этот формат, если это хорошая идея.

Ответы [ 9 ]

6 голосов
/ 05 февраля 2009

Этот URL:

"campaign/{destination}/{partnerid}/{campaignid}/{custom}",

... для меня это не ресурс, а вызов удаленного метода. Здесь много бизнес-логики, которая может измениться в будущем. Кроме того, это сложно. Мой инстинкт инстинкта при разработке URL-адресов - проще, чем обычно Это удваивается при передаче URL-адреса внешнему партнеру.

Униформа Ресурс Локаторы должны указывать ресурсы. Пункт назначения, безусловно, является ресурсом (но об этом чуть позже), и я думаю, что вы можете считать кампанию ресурсом. Партнер - это не ресурс, которому вы служите. Custom, конечно, не является ресурсом, так как он полностью не определен.

Я слышу, что вы говорите о нежелании говорить партнерам "создать кампанию", но учтите, что в любом случае вам, вероятно, придется пойти по этому пути. Как только в кампании появятся какие-либо свойства, отличные от идентификатора партнера, вам в основном придется это сделать.

Итак, мои первые выводы заключаются в том, что вам, вероятно, следует избавиться от идентификатора партнера и извлечь его из кампании. Избавьтесь также от custom и используйте вместо этого параметры строки запроса, если это будет необходимо. Для указания способа возврата ресурса целесообразно использовать параметры строки запроса (в отличие от идентификатора ресурса).

Снятие этих урожаев:

"campaign/{destination}/{campaignid}",

Хорошо, это проще, но все равно выглядит неправильно. Что делает пункт назначения между кампанией и идентификатором кампании? Один из подходов заключается в перестановке вещей:

"campaign/{campaignid}/{destination}",

Другой вариант - использовать индексацию в стиле Astoria:

"campaign({campaignid})/{destination}",

По некоторым причинам, это выглядит странно для многих людей, но это совершенно законно. Не стесняйтесь использовать другие юридические символы, чтобы отделить кампанию от идентификатора; Дело в том, что / не является единственным выбором, и, возможно, не является подходящим выбором.

Однако ...

Один вопрос, который мы еще не рассмотрели, это то, что должно произойти, если / когда пользователь отправит действительное место назначения, но неверный идентификатор кампании или партнера. Если правильный ответ заключается в том, что пользователь должен увидеть ошибку, то все вышеперечисленное остается в силе. Если, с другой стороны, правильный ответ заключается в том, что пользователь все равно должен быть незаметно перенаправлен на целевую страницу, тогда идентификатор кампании действительно является параметром строки запроса, а не частью ресурса. Возможно, некоторым партнерам не хотелось бы получать URL-адрес со знаком вопроса, но с чисто REST-точки зрения я считаю, что это правильный подход, если действительность идентификатора кампании не определяет, где находится пользователь. В этом случае URL будет:

"campaign/{destination}",

... и вы добавите параметр строки запроса с идентификатором кампании.

Я понимаю, что не дал вам однозначного ответа на ваш вопрос. Проблема в том, что большая часть этого основана на деловых соображениях, о которых вы, вероятно, знаете, но я, конечно, нет. Поэтому я больше пытаюсь раскрыть философию REST-полного URL-адреса, чем пытаться объяснить вам свой бизнес. :)

3 голосов
/ 10 февраля 2009

Я думаю, что в последнее время переписывание URL выходит из-под контроля. Не все принадлежит URL. В конце концов, URL-адрес должен описывать ресурс, который можно искать, обнаруживать или манипулировать им, и мне кажется, что по крайней мере идентификатор партнера и настраиваемые поля сверху не являются частью ресурса.

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

1 голос
/ 10 февраля 2009

Думаю, я бы смотрел на это так, как это делает SO.

"campaign/{campaign-id}/friendly-name-of-campaign"

Создайте отображение в вашей базе данных при создании кампании, которое связывает все необходимые данные с автоматически сгенерированным идентификатором. Дружественное имя может быть назначено пользователем в основном так же, как вопрос о SO - но у вас также может быть процесс утверждения, который гарантирует, что он соответствует вашим требованиям и отличается от любых существующих названий кампаний. Ваша компания по отслеживанию может отслеживать по идентификатору, и вы можете сопоставить это с вашими связанными данными простым поиском.

1 голос
/ 09 февраля 2009

Почему бы не использовать URL-кодированные переменные вместо маршрутов? Они гораздо более гибкие - вы можете добавлять любые новые функции в будущем, сохраняя при этом 100% обратную совместимость. По общему признанию, вводить вручную немного сложнее, но если все-таки есть все эти параметры, это уже не пикник.

http://mysite.com/page?campaign=1&dest=products&pid=15&cid=25

Для меня это гораздо более показательно, что на самом деле происходит. Использование путей подразумевает, что ресурс существует в этом месте. Но на самом деле вы просто предоставляете веб-сервис с различными параметрами, и эта модель отражает это гораздо более четко. И в будущем вы можете добавить больше параметров без особых усилий. Вы также можете использовать параметры по умолчанию, если они отсутствуют, ничего не испортив.

Не уверен в коде в ASP, но его реализация должна быть тривиальной.

1 голос
/ 31 января 2009

Похоже, вы покрыли все свои базы. Единственное предложение, которое у меня есть, это изменить

{custom}

до

{*custom}

Таким образом, если вам когда-либо потребуется принять дополнительные параметры, вам не нужно рисковать, что старые URL получат 404. Например:

Если у вас есть URL, который выглядит следующим образом:

кампании / PR / SO / 123

и в будущем вы решите, что хотите принять четвертый и пятый параметры:

кампания / PR / SO / 123 / л / Foo

, тогда первый URL будет по-прежнему действительным, потому что вы используете подстановочный знак в {* custom}. "бла / фу" будет передаваться как строка для вашего действия. Чтобы получить эти два дополнительных параметра, вы просто разделите пользовательский аргумент в вашем действии на «/». Добавьте дружественную обработку ошибок, если они не существуют, и вы успешно изменили объем информации, которую вы можете получить с URL-адресом кампании, не нарушая полностью URL-адреса, уже находящиеся в открытом доступе.

0 голосов
/ 10 февраля 2009

Самая важная вещь, которую я узнал о REST URL, обычно хоронится в какой-то книге или статье:

URL должен указывать на ресурс, а следующая строка запроса должна содержать всю необходимую информацию о области видимости. НЕ смешивайте эти два, иначе у вас будет очень сложный дизайн.

Кроме того, я полностью согласен с Крейгом Штунцем

0 голосов
/ 10 февраля 2009

Создать URL с именем http://mysite.com/gateway

Верните HTML-форму, скажите партнерам, чтобы они заполнили форму и отправили ее. Перенаправление на основе значений формы.

Вы можете легко предоставить своим партнерам javascript для выполнения GET и POST. Должно быть тривиально.

0 голосов
/ 10 февраля 2009

Я бы сделал

/c/{destination}/{partnerid}/{campaignid}/?customvar=s

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

Из вашего описания, пункт назначения представляется наиболее широким параметром, partnerid работает только с пунктом назначения, а campaingid относится только к партнеру.

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

Вы также не должны пытаться быть слишком RESTful здесь. В конце концов, это для кампании и для перенаправления на конечный ресурс. Таким образом, URL, который вы хотите создать здесь, на самом деле не является конкретным ресурсом с точки зрения REST.

0 голосов
/ 09 февраля 2009

То, что у вас есть, выглядит хорошо для ваших нужд. Другие посты здесь имеют хорошие моменты. Но, возможно, не подходит для вас. Одна вещь, которую вы могли бы рассмотреть при проверке ваших ссылок в будущем, это указать номер версии где-то там.

"campaign/{version}/{destination}/{partnerid}/{campaignid}/{custom}"

Таким образом, если вы решите полностью изменить свой формат, вы можете повысить версию до 2.0 (или чего-либо другого) и все еще отслеживать старые входящие ссылки.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...