这是一个创建于 2387 天前的主题，其中的信息可能已经有所发展或是发生改变。
如果是小团队，或者产品还在早期，写一个规范严格的 restful 接口有必要吗？实际开发中，需要什么接口就增加，字段定义按业务需求来，不是更加 make sense? 如果接口是内部系统使用，用不着写漂亮的 restful 给别人看，这是我的看法。
 |
1
littleylv 2018-05-30 11:17:31 +08:00
小项目的话怎么开心怎么来
|
 |
2
df4VW 2018-05-30 11:22:17 +08:00  1
因为资源是相对固定的，但是业务逻辑是不断变换的，以资源为核心，restful 通过组合拼装不同的资源接口，可以高效的完成复用
|
 |
3
prolic 2018-05-30 11:24:45 +08:00 1
没什么好，表达能力太差，唯一可以借鉴的就是前后端职责，后台只统一提供资源的增删改查
|
 |
4
WuwuGin 2018-05-30 11:25:16 +08:00 via Android
就像编程语言都有格式规范，软件工程也有各种设计模式一样，这些都不是强制或是必须的，但是在大型项目多人合作的情况下，这些规范的意义就显现出来了。
你的问题和为什么推荐用驼峰命名法一样，只要你能和团队沟通协调到位，用 a，b，c 命名变量也无所谓。 |
 |
5
awing 2018-05-30 11:35:06 +08:00
我觉得这问题等同于 `约定大于规则有什么好？`
|
 |
6
ddbullfrog 2018-05-30 12:04:10 +08:00
graphql
|
 |
7
kaedea 2018-05-30 13:03:15 +08:00 via Android
semantic url api
|
 |
8
instein 2018-05-30 14:26:27 +08:00
如果是一两个人， 想怎么写都行
|
 |
9
swulling 2018-05-30 14:28:47 +08:00 via iPhone
进来之前我以为批评的是 restful 接口太随意，rpc 大法好之类的
结果是嫌 restful 接口规矩太多… |
 |
10
HypoChen 2018-05-30 14:41:37 +08:00
小项目怎么开心怎么写就可以啊
在项目不大团队不大用户量不大的情况下，谈架构谈规范谈性能都是拉低都是没啥实际好处的事情 但反之，大型项目依赖规范，能减少人为失误 |
|
11
HypoChen 2018-05-30 14:42:18 +08:00
fix：拉低工作饱和度
|
 |
12
dilu 2018-05-30 14:59:10 +08:00
在我看来最大的好处，一个是有利于前后端分离，一个是以后你的项目可能会有 IOS/Android/小程序 /balabala 等，这样后端只写一次就 OK 了
|
 |
13
CFO 2018-05-30 15:02:32 +08:00 via Android
不用 restful 还得去给方法起名字 多累啊
|
 |
14
limbo0 2018-05-30 16:28:44 +08:00 via Android
有必要，太随便让接手的人头疼
|
 |
15
cctv1005s927 2018-05-30 18:42:00 +08:00
- 项目写完，不再维护，不需要。
- 项目写完，需要维护，需要，并且严格控制代码质量。 |
 |
16
ooh 2018-05-30 19:32:46 +08:00 via Android
lz 是不是不喜欢戴套
|
 |
17
fuxiaohei 2018-05-30 19:40:41 +08:00
restful 本身是一种推荐范式，不代表要照着做
小规模爱咋写咋写 规模大必须有规范好 |
 |
18
finian 2018-05-30 19:45:06 +08:00
GraphQL 了解一下
|
 |
19
TommyLemon 2018-07-16 19:09:30 +08:00
用 APIJSON，大部分增删改查接口都不用写了。
自动将前端传的请求 JSON 转为 SQL 语句，执行后返回对应结构的 JSON 结果。 APIJSON，让后端接口和文档自动化，前端(客户端) 定制返回 JSON 的数据和结构！ github.com/TommyLemon/APIJSON |
Select Language