Resultful Url 设计原则

许多 Web 组件和框架将平等对待以下两个 URI：
http://api.canvas.com/shapes/
http://api.canvas.com/shapes
但不是所有框架都支持，可能有些会返回301 错误

在 URI 的路径部分的正斜杠（/），用于表示资源之间的层次关系。

例如：
http://api.example.com/blogs/guy-levin/posts/this-is-my-first-post

文本查看器（如浏览器，编辑器等）经常在 URI 下加下划线，以提供可点击的视觉提示。 根据应用程序的字体，下划线（_）字符可能被这个下划线部分地遮蔽或完全隐藏。
为避免这种混淆，请使用连字符（ - ）而不是下划线

方便的话，URI 路径中首选小写字母，因为大写字母有时会导致问题。 例如：RFC 3986 中将 URI 定义为区分大小写，但协议头和域名除外。

例如：
http://api.example.com/my-folder/my-doc
HTTP://API.EXAMPLE.COM/my-folder/my-doc

在 URI 格式规范（RFC 3986）中这两个 URI 是相同的。

http://api.example.com/My-Folder/my-doc
而这个 URI 与上面的两个却是不同的。

在 Web 上，字符（.）通常用于分隔 URI 的文件名和扩展名。
一个 REST API 不应在 URI 中包含人造的文件扩展名，来表示消息实体的格式。 相反，他们应该通过 header 头中 Content-Type 属性的媒体类型来确定如何处理实体的内容。
http://api.college.com/students/3248234/courses/2005/fall.json
http://api.college.com/students/3248234/courses/2005/fall
不应使用文件扩展名来表示格式偏好。
应鼓励 REST API 客户端使用 HTTP 提供的格式选择机制，即请求 header 中的 Accept 属性。
为了实现简单的链接和调试的便捷，REST API 也可以通过查询参数来支持媒体类型的选择。