代码之家  ›  专栏  ›  技术社区  ›  Droo

在rest-uri中使用什么作为空间?

  •  14
  • Droo  · 技术社区  · 15 年前

    我应该使用什么:

    • /findby/姓名/名姓
    • /findby/姓名/名字-名字
    • /findby/姓名/名姓
    • /findby/name/first/first/last/last

    等。

    URI表示一个名为1的人员资源,但我需要从逻辑上将第一个和最后一个分开来标识每个人。我有点喜欢最后一个例子,因为我可以做到:

    • /findby/name/first/first
    • /findby/姓名/姓氏/姓氏
    • /findby/name/first/first/last/last
    5 回复  |  直到 11 年前
        1
  •  13
  •   Joel Martinez    15 年前

    您可以始终只接受空格:-)(querystring转义为%20)

    但我的偏好是只使用破折号(-)。在URL中看起来更好。除非您需要基本上能够查询,在这种情况下,最后一个示例会更好,如您所指出的那样

        2
  •  13
  •   Nas Banov    11 年前

    为什么不使用 + 为了空间?

    我迷路了:破折号,减号,下划线,%20…为什么不只用 + ?这就是查询参数中空间通常是如何编码的。是的,你也可以用20%,但是为什么,看起来很难看。

    我愿意

    /personNamed/Joe+Blow
    
        3
  •  2
  •   Leventix    15 年前

    我喜欢使用“uu”,因为它是保持URL可读性的最类似于空格的字符。

    但是,您提供的URL看起来并不那么安全。URL应该表示一个资源,但在您的例子中它表示一个搜索查询。所以我会这样做:

    /people/{first}_{last}
    /people/{first}_{last}_(2)  - in case there are duplicate names
    

    这个箱子你得把弹头放在里面( {first}_{last} ,请 {first}_{last}_(2) )对于每个用户记录。另一个选项是预先准备好ID,这样您就不必费心处理slugs了:

    /people/{id}-{first}_{last}
    

    对于搜索,您可以使用非RESTful URL:

    /people/search?last={last}&first={first}
    

    它们将显示搜索结果列表,而页面上方的URL将显示特定人员的搜索结果列表。

    我不认为有任何使用使搜索网址的安宁,用户很可能会想共享链接到某个人的网页,而不是搜索结果页。对于搜索引擎,避免在多个URL中使用相同的内容,甚至应该拒绝在robots.txt中对搜索结果页进行索引。

        4
  •  2
  •   yfeldblum    15 年前

    搜索:

    /people/search?first={first}&last={last}
    /people/search?first=george&last=washington
    

    对于资源路径:

    /people/{id}-{first}-{last}
    /people/35-george-washington
    

    如果您在标准配置中使用RubyonRailsv3,那么下面是您可以做到的方法。

    # set up the /people/{param} piece
    # config/routes.rb
    My::Application.routes.draw do
      resources :people
    end
    
    # set up that {param} should be {id}-{first}-{last}
    # app/models/person.rb
    class Person < ActiveRecord::Base
      def to_param
        "#{id}-#{to_slug(first_name)}-#{to_slug(last_name)}"
      end
    end
    

    注意你的建议, /findby/name/first/{first}/last/{last} ,不是休息的。它不命名资源,也不简洁地命名资源。

        5
  •  0
  •   Philzen    11 年前

    最复杂的选择应该始终考虑两个禁忌:

    1. 因为你永远不知道开发人员或正在实现的设备在处理URLEndoding方面有多熟练,所以我总是试图限制自己 the table of safe characters 如《好话》中所述 (Please) Stop Using Unsafe Characters in URLs
    2. 另外-我们想考虑使用API的客户机。我们能在客户端编程语言中轻松地表示和访问整个结构吗?有什么特别的角色 请求留给我们?即A $ 在javascript变量名中是很好的,因此可以直接在解析的结果中访问,但是PHP客户机仍然需要使用更复杂(而且可能更混乱)的表示法。 $userResult->{'$mostVisited'}->someProperty …那是你自己脚上的一枪!因此,对于这两个(以及其他一些编程环境),下划线似乎是唯一有效的选择。

    否则,我基本上同意@yfeldblum的回答——我将区分搜索端点和实际的唯一资源查找。我觉得休息得更好,但更重要的是,两个人 重大成本差异 在您的API服务器上——这样您就可以更容易地区分,也就是说,如果您需要的话,可以收取更高的成本或限制搜索端点的速率。

    be Pragmatic 与“Restafarian”相反,上述方法 /people/35-george-washington 可以(并且应该是imho)基本上只响应ID,所以如果您想要一个命名的、用于dummies链接的urlsafe,请将引用列为 /people/35_george_washington . 其他想法可能是 /people/35/#GeorgeWashington (因此打破了成吨的RFC)或 /people/35_GeorgeWashington -API不在乎。