Routes for community #947
Routes for community #947
Conversation
|
Skipping CI for Draft Pull Request. |
| component: () => import('@/pages/community/projects.vue') | ||
| }, | ||
| { | ||
| path: '/user/:name', |
There was a problem hiding this comment.
关于这种 path style，我在想如果对于资源集合咱们使用复数（比如 /projects），那对于特定资源实例如果用“复数集合+标识符“的格式看起来会不会更统一些？比如，/users/:name。
另外，咱们不使用类似 twitter、github 那种资源所有者优先的 path style 的主要原因是什么？是关键词保留方面的吗？
There was a problem hiding this comment.
关于这种 path style，我在想如果对于资源集合咱们使用复数（比如
/projects），那对于特定资源实例如果用“复数集合+标识符“的格式看起来会不会更统一些？比如，/users/:name。
这个是目前 spx-backend HTTP 接口的路由风格，对于资源集合的操作（如列举），就用复数；对于单个资源，则单数 + 标识
你说的总是用复数的方式我觉得也 OK 的，只是这二者间，这里会倾向跟已有的风格一致
另外，咱们不使用类似 twitter、github 那种资源所有者优先的 path style 的主要原因是什么？是关键词保留方面的吗？
Github 是 /:user/:repo，Twitter 是 /:user/status/:id，在 :user 这里确实会容易有路由冲突的问题，虽然不是不能解决，不过感觉好处有限
There was a problem hiding this comment.
关于这种 path style，我在想如果对于资源集合咱们使用复数（比如
/projects），那对于特定资源实例如果用“复数集合+标识符“的格式看起来会不会更统一些？比如，/users/:name。这个是目前 HTTP 接口的路由风格，对于资源集合的操作（如列举），就用复数；对于单个资源，则单数 + 标识
你说的总是用复数的方式我觉得也 OK 的，只是这二者间，这里会倾向跟已有的风格一致
其实我挺想改一下接口的整体风格的，改得更 RESTful 些，只不过牵扯到兼容性问题不太好下手。
我在想对于类似 path style 这种后期很难再做改动的东西来说，咱们是不是可以尽量向 github 靠拢？感觉他们的大多数风格都挺优雅的。
另外，咱们不使用类似 twitter、github 那种资源所有者优先的 path style 的主要原因是什么？是关键词保留方面的吗？
Github 是
/:user/:repo，Twitter 是/:user/status/:id，在:user` 这里确实会容易有路由冲突的问题，虽然不是不能解决，不过感觉好处有限
嗯想了一下好处是有限，主要好处可能是短一点分享的时候会方便些。咱们可以先不用这种风格。就算后面因为某些原因想用了也可以换过去，而且应该不会造成什么兼容性问题。
There was a problem hiding this comment.
我在想对于类似 path style 这种后期很难再做改动的东西来说，咱们是不是可以尽量向 github 靠拢？感觉他们的大多数风格都挺优雅的。
是的，不过 github 自己也有一些混乱的地方；比如 pull 跟 commit 都是像上面说的“对资源集合复数，对单个资源单数”（这个风格我觉得也是逻辑自洽的），而 issue、project 这些又像你说的“都是复数”
就算后面因为某些原因想用了也可以换过去，而且应该不会造成什么兼容性问题。
哈哈哈会有问题吧，如果用户名叫“explore”或者“projects”，他的个人主页就没法访问了..Twitter 用户应该就不能起名叫“explore”或者“notifications”？这个是我不喜欢这种路由的主要原因
There was a problem hiding this comment.
以及 Github 的 /:owner/:repo 这种路由风格的实施好像后来也遇到了障碍，对于 organization，其 repo 的路由还是 /:owner/:repo，但是
这些就变成多了个 /orgs 前缀；我不太清楚这里边具体的原因，但是这种不一致应该是不得已
There was a problem hiding this comment.
如果用户名叫“explore”或者“projects”，他的个人主页就没法访问了
对是的，刚我也想到了，但我想的是 oauth provider 会帮咱们屏蔽掉一些关键词。不过我忽略了咱们后面还会引入邮箱登录允许自定义用户名……
There was a problem hiding this comment.
以及 Github 的
/:owner/:repo这种路由风格的实施好像后来也遇到了障碍，对于 organization，其 repo 的路由还是/:owner/:repo，但是这些就变成多了个
/orgs前缀；我不太清楚这里边具体的原因，但是这种不一致应该是不得已
嗯同意不要用这种风格了，感觉引入的问题远比好处多
There was a problem hiding this comment.
是的，不过 github 自己也有一些混乱的地方；比如 pull 跟 commit 都是像上面说的“对资源集合复数，对单个资源单数”（这个风格我觉得也是逻辑自洽的），而 issue、project 这些又像你说的“都是复数”
嗯 github 确实也不是完全统一的……
对于 /users/:user 这种风格来说，应该是把每一级都看作“目录”。所以 /users 表示目录本身，/users/:user 表示目录下的具体项。
倒也不是非得遵循这种目录结构风格。想了一下如果遵循“对资源集合复数，对单个资源单数”，这样接口改动也会更小一些。
|
This PR has been deployed to the preview environment. You can explore it using the preview URL. Warning Please note that deployments in the preview environment are temporary and will be automatically cleaned up after a certain period. Make sure to explore it before it is removed. For any questions, contact the Go+ Builder team. |
close #940