2

重要提示:这个问题实际上并不是一个真正的 ASP.NET 问题。任何对 URLS 有所了解的人都可以回答。我只是碰巧使用了 ASP.NET 路由,所以包含了这个细节。

简而言之,我的问题是:

“我应该设计什么样的 URL 格式,我可以将其提供给外部各方,以到达我网站上的特定位置,这将是未来的证明。[我是创建这些 'REST' URL 的新手]。”


我需要一个 ASP.NET 路由 URL,该 URL 将提供给第三方以跟踪营销活动。它本质上是一个“网关” URL,将用户重定向到我们网站上的特定页面,该页面可能是主页、特殊竞赛或特定产品。

除了尝试捕获推荐人之外,我还需要接收一个合作伙伴 ID、一个活动编号和可能的其他参数。我想提供一条路线来做到这一点,但我想第一次把它做好,因为很明显,一旦它被外部使用,我就不能轻易地改变它。

这样的东西看起来怎么样?

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”这样的神秘事物。

目的地:指示链接将把用户带到我们网站上的哪个页面。例如 PR 将用户引导到产品页面。

partnerid:我们分配的公司 ID - 例如堆栈溢出的 SO。

Campaignid:活动 ID,例如 123 - 每个合作伙伴唯一。我已经意识到,我认为我更希望 3rd 方公司能够自己管理活动 ID,而不是我们提供一个网站来“创建活动”。不过,我还不完全确定这一点。

custom:自定义数据(可选)。我可以在不破坏现有 URL 的情况下添加更多自定义数据参数

注意:我有“目的地”的原因是因为活动 ID 是由客户决定的,所以他们还需要告诉我们该活动的目的地在哪里。或者,他们可以向我们“注册”一个活动。这可能是避免人们输入随机广告系列 ID 的更好解决方案,但我并不太担心这一点,我认为这个系统提供了更大的灵活性。

此外,我们可能还想知道他们用来链接到我们的图片(这样我们就可以跟踪哪个横幅效果最好)。我认为这是一个新的活动 ID 的候选人,而不是自定义数据字段,但我不确定。

目前我正在使用一个非常原始的 URL,例如http://example.com?cid=123。在这种情况下,广告系列 ID 需要发给第三方,这不是一个非常灵活的系统。我想立即转移到新客户的新系统。

对未来验证这个系统有什么想法吗?我可能错过了什么?我知道我总是可以添加新格式,但如果这是个好主意,我想尽可能多地使用这种格式。

4

9 回答 9

6

这个网址:

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

...在我看来不像资源,它看起来像远程方法调用。这里有很多业务逻辑,将来可能会发生变化。此外,它很复杂。在设计 URL 时,我的直觉是越简单通常越好。当您将 URL 交给外部合作伙伴时,这会增加一倍。

统一资源定位器应该指定资源。目的地当然是一种资源(稍后会详细介绍),我认为您可以将广告系列视为一种资源。合作伙伴不是您服务的资源。自定义当然不是资源,因为它完全未定义。

我听到你说不想告诉合作伙伴“创建一个活动”,但考虑到你最终可能不得不走这条路。只要广告系列具有合作伙伴标识符以外的任何属性,您就必须这样做。

因此,我首先得出的结论是,您可能应该摆脱合作伙伴 ID,并从广告系列中获取它。如果有必要,也可以摆脱自定义,并使用查询字符串参数。使用查询字符串参数来指定如何返回资源(而不是资源的标识)是合适的。

删除这些产量:

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

好的,这更简单,但它仍然看起来不正确。广告系列和广告系列 ID 之间的目的地在做什么?一种方法是重新排列事物:

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

另一个是使用 Astoria 风格的索引:

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

出于某种原因,这对很多人来说看起来很奇怪,但它是完全合法的。随意使用其他合法字符将活动与 ID 分开;这里的重点是 / 不是唯一的选择,也可能不是合适的选择。

然而...

我们尚未讨论的一个问题是,如果/当用户提交了一个有效的目的地,但一个无效的广告系列或合作伙伴 ID 时会发生什么。如果正确的响应是用户应该看到错误,那么以上所有内容仍然有效。另一方面,如果正确的响应是无论如何都应该默默地将用户带到目标页面,那么活动 ID 实际上是一个查询字符串参数,而不是资源的一部分。或许有些合作伙伴不希望得到一个带有问号的 URL,但从纯粹的 REST 角度来看,我认为这是正确的方法,如果活动 ID 的有效性不能确定用户最终的位置。在这种情况下,URL 将是:

"campaign/{destination}",

...您将添加一个带有广告系列 ID 的查询字符串参数。

我意识到我没有给你一个明确的答案来回答你的问题。问题在于,这大部分取决于您可能知道的商业考虑,但我当然不是。因此,我更多地尝试介绍 REST-ful URL 的理念,而不是尝试向您解释您的业务。:)

于 2009-02-05T14:47:54.730 回答
3

我认为 URL 重写最近有点失控。并非所有内容都属于 URL。毕竟,URL 应该描述可以搜索、发现或操作的资源,在我看来,至少上面的合作伙伴 ID 和自定义字段不是资源的一部分。

更不用说在某些时候您实际上希望在多个广告系列中保持合作伙伴 ID 不变,这意味着它现在与他们需要访问的特定地点正交。如果您将这些作为参数保留,您将允许您的合作伙伴统一访问您网站上的多个资源,同时仍然可靠地识别自己,因此您可以跟踪他们对您的任何活动的参与。

于 2009-02-10T04:23:14.770 回答
1

看起来你已经覆盖了所有的基础。我唯一的建议是改变

{custom}

{*custom}

这样,如果您需要接受更多参数,您就不必冒险让旧 URL 得到 404。例如:

如果您的 URL 如下所示:

竞选/PR/SO/123

并且您决定将来要接受第四个和第五个参数:

竞选/PR/SO/123/blah/foo

那么第一个 URL 仍然有效,因为您在 {*custom} 中使用了通配符。"blah/foo" 将作为字符串传递给您的操作。要获得这两个额外的参数,您只需将操作中的自定义参数用“/”拆分即可。添加一些友好的错误处理,如果它们不存在并且您已经成功地更改了您可以通过活动 URL 接收的信息量,而不会完全破坏已经存在的 URL。

于 2009-01-31T16:13:24.733 回答
1

为什么不使用 URL 编码变量而不是路由?它们更加灵活——您可以在未来添加任何新功能,同时仍保持 100% 的向后兼容性。诚然,手动打字有点麻烦,但如果反正有所有这些参数,那已经不是野餐了。

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

对我来说,这更能说明正在发生的事情。使用路径意味着资源存在于该位置。但实际上,您只是提供了一个带有各种参数的 Web 服务,而这个模型更清楚地捕捉到了这一点。将来,您可以毫不费力地添加更多参数。如果它们丢失,您也可以默认参数而不会弄乱任何东西。

不确定 ASP 中的代码,但实现起来应该很简单。

于 2009-02-09T17:39:43.490 回答
1

我想我会像 SO 那样做问题。

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

创建活动时在数据库中创建一个映射,将您需要的所有数据与自动生成的 ID 相关联。友好名称的分配方式基本上与 SO 上的问题相同——由用户——但您也可以有一个批准过程,以确保它满足您的要求并且与任何现有的活动名称不同。您的跟踪公司可以通过 id 进行跟踪,并且您可以通过简单的查找将其与关联数据相关联。

于 2009-02-10T02:44:18.593 回答
0

您拥有的东西看起来很适合您的需求。这里的其他帖子有很好的观点。但可能不适合你。在将来对链接进行校对时,您可以考虑的一件事是在其中的某处放置一个版本号。

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

这样,如果您决定完全更改格式,您可以将版本升级到 2.0(或其他),并且仍然跟踪进来的旧链接。

于 2009-02-09T13:31:37.300 回答
0

我会做

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

您应该考虑第一个参数的层次结构,您已经很好地管理了它。仅当存在层次结构路径段时才应使用。

根据您的描述,目的地似乎是最广泛的参数,partnerid 仅适用于目的地,而 campaingid 特定于合作伙伴。

当您确实需要添加自定义参数时,我会选择查询变量(它们在 REST 中不被禁止),因为它们不是层次结构的一部分。

你也不应该在这里尝试太 RESTful。毕竟,它是针对活动和重定向到最终资源的。所以你想在这里设计的 URL 并不是真正的 REST 术语中的特定资源。

于 2009-02-10T16:15:24.877 回答
0

创建一个名为http://mysite.com/gateway的 URL

返回一个 HTML 表单,告诉您的合作伙伴填写表单并发布。根据表单值重定向。

您可以轻松地为您的合作伙伴提供 javascript 来执行 GET 和 POST。应该是微不足道的。

于 2009-02-10T18:13:37.933 回答
0

我学到的关于 REST URL 的最重要的事情通常深藏在一些书或文章中:

URL 应该指向一个资源,并且下面的 ?querystring 应该包含所有需要的范围信息。不要将这两者混为一谈,否则您将拥有一个很难使用的设计。

除此之外,我完全同意 Craig Stuntz

于 2009-02-10T20:43:18.510 回答