一切脱离实际生产的设计，都是不合理的。任何时候都一样。
完全以Restful开发也是不合理的。
实际接口定义，要以实际的项目的时间性考虑。
时间急，你还不熟悉restful的形式，完全没必要强制restful。只要你的前端不骂你，就OK。
但是必须有自己一套的设计。最起码符合项目需要。你Leader觉得没问题就OK。Leader也是千人千面，各有各的喜好，没有绝对的好。

什么是URL？

URI

REST API 使用统一资源标识符（URI）来寻址资源。在今天的网站上，URI 设计范围从可以清楚地传达API的资源模型，

如：http://api.example.com/louvre/leonardo-da-vinci/mona-lisa

到那些难以让人理解的，比如：http://api.example.com/68dd0-a9d3-11e0-9f1c-0800200c9a66

在深入了解规则之前，先看一下在 RFC 3986 中定义的通用 URI 语法，如下所示：URI = scheme "://" authority "/" path ["?" query] ["#" fragment]

规则

规则1：URI中不应包含尾随的斜杠（/）：即，最后一位 不应该是 “/”

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

规则2：正斜杠分隔符（/）必须用于指示层次关系

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

规则＃3：应使用连字符（ - ）来提高 URI 的可读性

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

规则4：不得在 URI 中使用下划线（_）

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

规则5：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 与上面的两个却是不同的。

规则 6：文件扩展名不应包含在 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 也可以通过查询参数来支持媒体类型的选择。

规则 7：端点名称是单数还是复数？

复数