Консультации необходимы по REST URL будут даны 3 стороны, чтобы получить доступ к своему сайту

голоса
2

Важно: Этот вопрос на самом деле не действительно вопрос ASP.NET. Тот , кто ничего не знает о URLS может ответить на него. Просто я использовать маршрутизацию ASP.NET, включенные таким образом, что подробно.

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

«Какой формат URL я должен разработать, что я могу дать внешним сторонам, чтобы добраться до определенного места на моем сайте, который будет на будущее. [Я новичок в создании 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. я мог бы изменить это просто что - то загадочным , как «с».

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

Partnerid : идентификатор для компании, мы назначили - такие , как SO переполнения стека.

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

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

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

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

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

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

Задан 30/01/2009 в 21:56
источник пользователем
На других языках...                            


9 ответов

голоса
6

Этот URL-адрес:

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

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

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

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

Так что мои первые к выводам, что вы, вероятно, следует избавиться от партнера ID, и вывести его из кампании. Избавиться от обычая, также, и использовать параметры строки запроса вместо этого, если это необходимо. Уместно использовать параметры строки запроса, чтобы указать, как вернуть ресурс (в отличие от идентичности ресурса).

Удаление этих выходов:

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

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

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

Еще бы использовать индексацию Astoria стиле:

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

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

Однако...

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

"campaign/{destination}",

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

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

Ответил 05/02/2009 в 15:47
источник пользователем

голоса
3

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

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

Ответил 10/02/2009 в 05:23
источник пользователем

голоса
1

Я думаю, что я смотрю на это делать так, что SO делает это вопросы.

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

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

Ответил 10/02/2009 в 03:44
источник пользователем

голоса
1

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

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

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

Не уверен, что часть кода в ASP, но это должно быть просто реализовать.

Ответил 09/02/2009 в 18:39
источник пользователем

голоса
1

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

{custom}

в

{*custom}

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

Если у вас есть URL, который выглядит примерно так:

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

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

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

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

Ответил 31/01/2009 в 17:13
источник пользователем

голоса
0

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

URL должен указывать на ресурс и следующий? QueryString должен необходима вся информации обзорной. DONT смешать те два или вы будете иметь дизайн Thats очень трудно работать.

Другое то, что я полностью согласен с Крейгом Stuntz

Ответил 10/02/2009 в 21:43
источник пользователем

голоса
0

Создание URL под названием http://mysite.com/gateway

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

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

Ответил 10/02/2009 в 19:13
источник пользователем

голоса
0

я бы сделал

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

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

Из вашего описания, назначение, кажется, широчайший параметр, Partnerid работает только с назначением, и campaingid специфичен к партнеру.

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

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

Ответил 10/02/2009 в 17:15
источник пользователем

голоса
0

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

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

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

Ответил 09/02/2009 в 14:31
источник пользователем

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more