大家用上RESTful的api了吗?
发布于 6 年前 作者 lzszone 6762 次浏览 来自 问答

如果用上了,感觉怎样? 如果没有,是因为什么?

刚到一个公司, 写个rest的小接口 客户端疯狂吐槽…教我咋写 我TM好气呀 T_T

28 回复

不怕,拿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 我个人觉得这样更好些

@meiwhu @lzszone 嗯 有些道理

再换个例子

比如我想获取用户数 count get /users 是获取用户列表 这里面倒是也有个count 不过用这个列表的话 资源就浪费了 多查了一下数据

怎么设计这个接口呢?

@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,不尴尬。

回到顶部