asp.net - 需要向第三方提供有关 REST URL 的建议以访问我的网站

Question

重要提示:这个问题实际上并不是真正的 ASP.NET 问题。任何了解 URL 的人都可以回答它。我只是碰巧使用 ASP.NET 路由，因此包含了该详细信息。

简而言之，我的问题是:

“我应该设计什么 URL 格式，以便外部各方能够访问我网站上的特定位置，这将是面向 future 的。[我是创建这些“REST”URL 的新手]。”

<小时/>

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

除了 trying to capture referrer我需要接收 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 
   }
); 

campaign:可能不希望实际链接中出现“campaign”一词，因为用户会在 URL 栏中看到它。我可能会将其更改为像“c”这样的神秘内容。

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

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

campaignid:广告事件 ID，例如 123 - 每个合作伙伴都是唯一的。我意识到我认为我更希望第三方公司能够自己管理事件 ID，而不是我们提供一个网站来“创建事件”。我不是 不过，对此还完全确定。

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

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

此外，我们想知道他们可能使用哪个图像链接到我们(以便我们可以跟踪哪个横幅效果最好)。我认为这是新的 CampaignID 的候选者，而不是自定义数据字段，但我不确定。

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

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

Answer 1

此网址:

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

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

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

我听到您所说的不想告诉合作伙伴“创建事件”，但考虑到您最终可能不得不走这条路。一旦广告系列具有合作伙伴标识符以外的任何属性，您几乎就必须执行此操作。

因此，我的第一个结论是，您可能应该删除合作伙伴 ID，并从营销事件中获取它。如果有必要，也摆脱自定义，并使用查询字符串参数。适合使用查询字符串参数来指定如何返回资源(而不是资源的标识)。

删除这些 yield :

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

好吧，这更简单了，但看起来仍然不对。目标在广告事件和广告事件 ID 之间执行什么操作？一种方法是重新安排事情:

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

另一种方法是使用 Astoria 风格的索引:

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

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

但是...

我们尚未讨论的一个问题是，如果/当用户提交有效的目的地，但广告系列或合作伙伴 ID 无效时，会发生什么情况。如果正确的响应是用户应该看到错误，则上述所有内容仍然有效。另一方面，如果正确的响应是用户无论如何都应该被静默地带到目标页面，那么营销事件 ID 实际上是一个查询字符串参数，而不是资源的一部分。也许有些合作伙伴不喜欢提供带有问号的 URL，但从纯粹的 REST 角度来看，如果营销事件 ID 的有效性不能确定用户最终到达的位置，我认为这是正确的方法。在本例中，URL 为:

"campaign/{destination}",

...您将添加带有广告事件 ID 的查询字符串参数。

我意识到我没有对你的问题给出明确的答案。问题在于，这大部分取决于商业考虑，您可能知道这一点，但我肯定不知道。因此，我更多地试图涵盖 REST-ful URL 的理念，而不是试图向您解释您的业务。 :)