当前位置：文江博客话题详情

REST URI 中的空格用什么？

发布于 2024-08-28 07:12:16 字数 409 浏览 6 评论 0原文

我应该使用什么：

/findby/name/{first}_{last}
/findby/name/{first}-{last}
/findby/name/{first};{last}
/findby/name/first/{first 名称

。

URI 表示具有 1 个名称的 Person 资源，但我需要在逻辑上将第一个名称与最后一个名称分开以识别每个我有点喜欢最后一个例子，因为我可以这样做：

/findby/name/first/{first}
/findby/name/last/{last}
/findby/name/first/{first}/last/{last}

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

仄言 2024-09-04 07:12:16

您始终可以只接受空格:-)（查询字符串转义为 %20）

但我更喜欢只使用破折号 (-) ...在 URL 中看起来更好。除非您需要能够进行基本查询，在这种情况下，最后一个示例更好，正如您所指出的

回复收藏 0 原文

冬天旳寂寞 2024-09-04 07:12:16

为什么不使用 `+` 来表示空格？

我不知所措：破折号、减号、下划线、%20...为什么不直接使用 + ？这就是查询参数中空格通常的编码方式。是的，你也可以使用 %20，但为什么看起来很难看。

我愿意

/personNamed/Joe+Blow

Why not use `+` for space?

I am at a loss: dashes, minuses, underscores, %20... why not just use +? This is how spaces are normally encoded in query parameters. Yes, you can use %20 too but why, looks ugly.

I'd do

/personNamed/Joe+Blow

回复收藏 0 原文

煮茶煮酒煮时光 2024-09-04 07:12:16

我喜欢使用“_”，因为它是与空格最相似的字符，可以保持 URL 的可读性。

但是，您提供的 URL 似乎并不是真正的 RESTful。 URL 应该代表资源，但在您的情况下它代表搜索查询。所以我会做这样的事情：

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

在这种情况下，你必须存储 slug ({first}_{last}, {first}_{last}_(2)) 对于每个用户记录。另一种选择是在 ID 前面添加，这样您就不必为 slugs 烦恼：

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

对于搜索，您可以使用非 RESTful URL：

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

这些将显示搜索结果列表，而 URL 位于特定人员的页面上方。

我认为将搜索 URL 设为 RESTful 没有任何用处，用户很可能希望共享指向某个人的页面而不是搜索结果页面的链接。对于搜索引擎，避免多个 URL 具有相同的内容，甚至应该拒绝在 robots.txt 中对搜索结果页面建立索引

I like using "_" because it is the most similar character to space that keeps the URL readable.

However, the URLs you provided don't seem really RESTful. A URL should represent a resource, but in your case it represents a search query. So I would do something like this:

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

It this case you have to store the slug ({first}_{last}, {first}_{last}_(2)) for each user record. Another option to prepend the ID, so you don't have to bother with slugs:

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

And for search you can use non-RESTful URLs:

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

These would display a list of search results while the URLs above the page for a particular person.

I don't think there is any use of making the search URLs RESTful, users will most likely want to share links to a certain person's page and not search result pages. As for the search engines, avoid having the same content for multiple URLs, and you should even deny indexing of your search result pages in robots.txt

回复收藏 0 原文

嘿哥们儿 2024-09-04 07:12:16

对于搜索：

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

对于资源路径：

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

如果您在标准配置中使用 Ruby on Rails v3，则可以按照以下方法进行操作。

# 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} 并不轻松。它没有命名资源，也没有简洁地命名它们。

For searching:

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

For resource paths:

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

If you are using Ruby on Rails v3 in standard configuration, here's how you can do it.

# 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

Note that your suggestion, /findby/name/first/{first}/last/{last}, is not restful. It does not name resources and it does not name them succinctly.

回复收藏 0 原文

彼岸花似海 2024-09-04 07:12:16

最复杂的选择应该始终首先考虑两个限制：

由于您永远不会知道开发人员或正在实现的设备在处理 urlencoding 方面有多熟练，因此我将始终尝试将自己限制为安全字符表，如出色的咆哮< a href="http://perishablepress.com/stop-using-unsafe-characters-in-urls" rel="nofollow noreferrer">（请）停止在网址中使用不安全字符
另外 - 我们要考虑使用 API 的客户端。我们能否在客户端编程语言中轻松表示和访问整个结构？这个要求会给我们留下什么特殊字符？即 $ 在 JavaScript 变量名中就可以了，因此可以在解析结果中直接访问，但是 PHP 客户端仍然必须使用更复杂（并且可能更令人困惑）的符号 $userResult ->{'$mostVisited'}->someProperty...搬起石头砸自己的脚！因此，对于这两个（以及其他几个编程环境），下划线似乎是唯一有效的选项。

否则，我基本上同意 @yfeldblum 的回应 - 我会区分搜索端点与实际的唯一资源查找。对我来说感觉更 REST，但更重要的是，两者在您的 api 服务器上有显着的成本差异 - 这样您可以更容易区分，即收取更高的成本或限制搜索端点的速率 - 如果您永远需要它。

为了务实，而不是“RESTafarian”，上述方法 / people/35-george-washington 可以（恕我直言）基本上只响应 id，所以如果您想要一个命名的 urlsafe-for-dummies-link，请将引用列为 /people/35_george_washington。其他想法可能是 /people/35/#GeorgeWashington （因此会破坏大量 RFC）或 /people/35_GeorgeWashington - API 不会关心。