问题标签 [url-design]

我对有关城市登陆页面的 URL 结构的想法很感兴趣。

基本上最佳实践和实施格式（a）优于（b）的原因：

(一) example.com/chicago
(二)example.com/?_city=chicago

我想知道这两种模式中哪一种会更好：

或者

目前我正在使用第一个，Whoops, looks like something went wrong.当我尝试时它给了我 a/photos/123/editxx而不是404 not found.

路线：

我不确定在哪里寻找错误，这些是photos路线：

getEdit() 和 postEdit()：

/photos/123/a/a/a/例如，当我输入时，出现相同的错误，抱怨主布局模板中的未定义变量。

控制器.php

看起来，如果有超过 2 个 URL 段，Controller.php 就不能正常工作。/domain.xy/1/2显示8但/domain.xy/1/2/3抛出错误Undefined variable: photos_online

我已经提供了这样的 REST API 来获取基本用户信息和用户空间信息。

/v1/users/{user_id}/profile，它将返回这样的 JSON：

```json {

“id”：123，“名称”：“foo”，“性别”：0，“电子邮件”：“foo@gmail.com”，}```

/v1/users/{user_id}/space，它也返回一个 JSON：

```json { "sum_space":100, "used_space":20, }

现在，如果客户端（例如网页，第三个应用程序）有一个视图需要同时显示部分用户信息（例如“姓名”，“性别”）和部分用户空间信息（例如“sum_space”） , 我需要提供一个新的聚合 API/v1/users/{user_id}吗？

如果我提供这样一个聚合 API，它应该返回 User 和 Space 的所有属性吗？如果我这样做了，返回值将包含一些未使用的值，这将增加网络的带宽。但是如果这个 API 只是返回客户需要的东西，如果新的客户需求来了，我该怎么办（例如，只获取用户名和用户的 used_space）？

如果我不提供任何聚合API，所有客户端必须调用N次才能获取N种资源。如果需要过滤器搜索（例如获取总空间> 100 的用户列表），则客户端只能连续执行此操作。

我对这些很困惑，有什么要遵循的指导方针吗？

为什么 Twitter (twimg.com) 使用大小的后缀（例如 ':large'）而不是查询参数？

例子：

从架构的角度来看，我觉得这很有趣，我想知道我是否遗漏了什么。
他们这样做是因为某些代理/客户端不缓存带有查询参数的网址吗？

任何人都可以对此有所了解吗？

为什么我看到的一些网站的形式是URL a.b.example，而另一些是形式的b.example/a？

例如，为什么用它gist.github.com代替github.com/gist？

我正在创建一个网站，现在是时候决定不同帖子的 URL 应该是什么样子了。

出于 SEO 目的，我打算添加帖子 URL，例如

为了防止 URL 崩溃，我正在考虑将帖子 ID 添加到 URL，例如

您如何看待将帖子 ID 添加到 URL 中，是否存在任何安全问题？我应该在添加到 URL 之前对 ID 进行哈希处理吗？我该怎么做？

在做一个小项目时，我现在有机会设计自己的 API。如果这不是一项商业活动，那么这是我了解更多关于 REST、资源、集合和 URI 的机会。

我的服务记录按时间序列组织的数据点，并将很快提供一个 API 来轻松查询特定系列的数据点范围。数据点是不可变的，因此应该是非常好的缓存候选者。时间序列只能在有限的时间窗口内更新，之后它们只能存档和读取（使它们也“可缓存”）。

我一直在研究一些提供同类服务的公司的API，发现了以下两种模式：

1. 定义路径中的系列和查询中的范围：

   /series/:id?from=2017-01-26&to=2017-01-27

   这几乎是大多数服务所使用的。我将其理解为系列是资源/集合，然后被切片到特定范围。从消费者的角度来看，这似乎很容易使用，但从数据的角度来看，查询中的日期是某种组织或层次结构的一部分，在这种情况下应该是路径的一部分。

2. 定义路径中的系列和坐标：

   /series/:x/:y/:z

   我没有找到时间序列的例子，但它是用于基于瓦片的地图服务的那种结构。x对我来说，这意味着 和 的每个组合y都是z一个不同的集合，在某些情况下可能包含或不包含相同的资源。它还直接映射到某个层次结构，/series/:x包含具有特定值的所有系列x和任何值yand z。

我真的很喜欢方法 2 的想法。我从以下内容开始：

• /series/:id（来自特定系列的所有数据点）

• /series/:id/:year（来自特定系列的所有数据点和year）

• /series/:id/:year/:month

• /series/:id/:year/:month/:day

• ...

这对于查询预定义范围非常有效，例如“2016 年的所有数据点”或“2016 年 1 月的所有数据点”。尝试查询“2016 年 1 月至 2016 年 3 月的所有数据点”等任意范围时会出现问题。

我的第一个试验是简单地将开始和结束添加到路径中：

• /series/:id/:year（特定年份的所有数据点）

• /series/:id/:fromyear/:toyearfromyear（和之间的所有数据点toyear）

但：

1. 它变得非常长，非常快。示例：/series/:id/:fromyear/:frommonth/:fromday/:toyear/:tomonth/:today并且可能非常麻烦，具体取决于所选的结构/series/:id/:fromyear/:toyear/:frommonth/:tomonth/:fromday/:today

2. 从层次结构或结构的角度来看，它没有任何意义。在/series/1/2014/2016, 2016 不是 2014 的子集，此集合实际上将返回 2014、2015 和 2016 的数据点。

3. 在服务器端处理起来很棘手。/series/1/2016/01/02应该返回 1 月 2 日或整个 1 月到 2 月范围内的所有数据点？

在注意到Github 在其片段中引用特定行或行范围的方式后，我尝试将范围定义为不同的集合，例如：

• /series/:id/:year/:month（和以前一样）
• /series/:id/:year/:frommonth-:tomonth（获得特定范围）
• /series/:id/:year/-:tomonth（得到从年初到的所有东西tomonth）
• /series/:id/:year/:frommonth-frommonth（从年底到年底得到所有东西）

现在，问题：

1. 我的解决方案是否破坏了任何 REST 或语义 URL 规则/概念/想法？
2. 与在查询中使用范围相比，它是否改善了缓存？
3. 它会损害消费者的可用性吗？
4. 它是不自然的还是违反了某些前端框架的不成文规则？

关于人们如何在 REST 中使用 URI，我已经看到了很多不同的答案。我倾向于对集合使用复数，对单一资源使用单数。但它需要更多的路由。

可以对所有资源使用复数吗？例如：

还是我应该坚持：

它在所有情况下都有效吗？在这种情况下，最佳做法是什么？

user假设s 和s之间存在一对多的关系comment，并且所有 id 都被提供为唯一的；

将操作命名为：

DELETE /users/{user_uuid}/comments/{comment_uuid}

或者

DELETE /comments/{comment_uuid}?

前者user_uuid是多余的，因为不需要删除评论。user_uuid只是为了让 url 看起来是 RESTful值得保留吗？

在 Stack Overflow 上针对 RESTful URL 设计提出了许多问题

仅举几例...

分层 URL 设计： 分层 RESTful URL 设计

了解 REST：动词、错误代码和身份验证：了解 REST：动词、错误代码和身份验证

所以我很清楚Restful URL Design。但是，对于不是单页应用程序 (SPA) 的传统网站的浏览器 URL 设计怎么样。

出于本示例的目的，假设我们有一个图书数据库。让我们进一步假设我们创建了 2 个传统的 HTML 站点。

1. 用于显示所有书籍的 HTML 表格
2. 用于显示一本书的 HTML 表单（空白或预先填写书籍详细信息）

现在我们希望我们网站的用户可以使用它进行 CRUD 操作。那么下面的 URL 设计怎么样：

问题：

最佳实践浏览器 URL 设计

我是否遵循浏览器中 URL 设计的最佳实践（我不是在这里谈论 REST）？还关于 SEO、书签和短 URL 设计？我在想类似的东西：/resource/action/ ...

仅 GET 和 POST URL 设计

除非有人使用 JavaScript，否则浏览器只能进行 GET 和 POST。考虑到上面的 URL 设计，引入 JavaScript 并发出 PUT 和 DELETE 请求来更新和删除资源是否更明智？或者我应该只使用 GET 和 POST 吗？

干杯