如果用上了,感觉怎样? 如果没有,是因为什么?
刚到一个公司, 写个rest的小接口 客户端疯狂吐槽…教我咋写 我TM好气呀 T_T
不怕,拿loopback和restify去打他们
先把你写的接口晒上来看看
restful !== http 请求+返回 JSON
反面教材
[GET] /api/bank/detail?id=xxx # 获取某个银行的详细信息
[GET] /api/bank/list?page=1&per_page=10 # 获取银行列表
[POST] /api/bank/create # 创建一条银行记录
[POST] /api/bank/update # 更新一条银行记录
[GET] /api/bank/delete?id=xxx # 删除一条银行记录
以前有个架构师这么写 restful API,如今坟头草已三丈高
这个网站对你可能有用 接口规范
想看接口
我个人理解,restful只是一种风格,不是一个规范。太较真真的没意思。 关键是接口统一,规范,好用。 比如我个人比较喜欢 [GET/POST] /api/goods/add [GET/POST] /api/goods/get [GET/POST] /api/goods/list [GET/POST] /api/goods/del 所有的参数都在form表单或者querystring里,你自己想怎么用就怎么用。只要是GET/POST 二选一,不混用就行~~
这个东西因人而异,nodejs中获取restful参数很方便,但是在java这类语言中获取参数就会复杂一些,大家宁愿所有请求都用post,这样代码更统一
@i5ting 嗯, 目前的情况只有标准心中存, 狗屎随手来
了, 主要是客户端前端习惯了以前的, 都不用这个…
@axetroy @dengnan123 接口已经被无情修改了 我举个例子吧 我希望的接口的样子:
get -> /users?skip=[]&limit=[] 用户列表
get -> /users/[id] 用户
post -> /users/ 新建
patch -> /users/[id] 修改
delete -> /users/[id] 删除
http status 尽量匹配错误类型
客户端希望的样子:
首先是结果返回…只要能连上服务器的, 响应头都是200, body里面再自己定义一个错误:{code, message}
类似这样,其中code自定义
然后已有的项目接口大概是…:
不是根据资源命名,而是类似: /getUserList
/createUser
url英语标识有部分不准确, 甚至错误,
不怕给大家贴一段我写前端的代码…
@fhawk @yuedun @CodeofGame
function correctPermissionProperty_childrens_with_children___justFuckTheseFuckingTypos_and_whyTheFuckIsTyposEverywhere(e) {
if(e.childrens) {
e.children = e.childrens.map(correctPermissionProperty_childrens_with_children___justFuckTheseFuckingTypos_and_whyTheFuckIsTyposEverywhere)
delete e.childrens
}
// FUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUCK!!!!!!!!!!!!!!!!!!!!!!!
return e
}
谢谢各位的提醒, 我觉得肯定要根据已有的情况去选择实现 但是前提是知道并理解http标准呀…
给他说 爱用不用
我现在用的全是post,数据一般全是JSON,path一般都是/user/create、/user/remove。 统一之后可以提取出更多的通用处理过程,我感觉很方便。 个人觉得restful看起来比较好看,用起来很麻烦。
@meiwhu 主要是用的时候,要在url里加参数,可能还要编码,一会get,一会post,比较烦~~
@meiwhu 我觉得是一样的吧…现在的httpClient都支持client.[http方法名]了, 你那样会拼接url, 当然是完全没问题的,只是协议提供的可以选择性的采用 我还是希望往协议上靠的
我问一个问题
get /users 是获取用户列表 get /users/:id 是获取某个用户的资料 post /users/:id 是更新某个用户 如果我有个方法 是验证Email是否可用 改怎么写呢? post /users/emailCheck ? 这就和更新用户资料哪儿重复了 也不能用 post /users/:id/emailCheck 因为没有当前用户的ID
目前我设计的是这种情况 post /user/emailCheck
感觉 不是很好
@cobola 怎么只有get,post,要用就用全家啊,head,patch,put,delete都用上,不然还不如学我😄。 你更新应该换成PUT /users/:id Email是否可用可以 HEAD /userEmail/:email
哎,感觉这都是形式,只要语义明确就行了,搞这些没多大用。
@lzszone 可能是我太懒了,方法名我都不想调用。贴个客户端的services代码:
import makeAPI from '../utils/makeAPI'
export default {
sufferer: {
login: makeAPI('/sufferer/login'),
create: makeAPI('/sufferer/create'),
update: makeAPI('/sufferer/update'),
remove: makeAPI('/sufferer/remove'),
findList: makeAPI('/sufferer/findList')
},
background: {
create: makeAPI('/background/create'),
update: makeAPI('/background/update'),
remove: makeAPI('/background/remove'),
findList: makeAPI('/background/findList'),
getIdNameMap: makeAPI('/background/getIdNameMap')
}
}
调用的时候: await services.sufferer.remove({ id: ‘1’ })
响应体带状态code 不用http statuscode表示响应状态,这样子接口会通用些~ justFuckTheseFuckingTypos 老哥稳
@cobola 这种情况其实该考虑email验证不属于用户模块的, 你可以做一个专门的验证模块, 包括短信也可以是下面的资源…
@axetroy 没用过restful,想知道这么写有什么不对吗或不好吗?
@Sunkaystar 这样写是没有约束的…比如一个/create, 我后端也可以写成/add, 比如list, 我可以写成all, 每个人的习惯不一样…(没有错误, 但是我还是偏向规律性好点的rest)
@fhawk get GET /api/book get GET /api/book/:id
create POST /api/book update PUT /api/book/:id delete DELETE /api/book/:id 我个人觉得这样更好些
@cobola get /users/count 固定的优先匹配,然后才是:id等变量
一直用泛型RESTfull。。。严格的REST没写过,也不想写
来自✨ Node.js开源项目精选✨
@meiwhu 严格的REST标准确实有点不太实用。如果是获取item列表,这post会不会比较尴尬。。我一般都是读get写post
来自✨ Node.js开源项目精选✨
什么,朕的大清亡了。
REST还不如公司(项目)内合理的强制的规范实用
@vendar 你师说我POST /user/findList 尴尬么?习惯就好😄,由于全部都是POST了,所以HTTP的方法名就不代表某个动作了,动作是findList,不尴尬。
http://graphql.cn/ Graphql 了解下?