这是一个创建于 1450 天前的主题，其中的信息可能已经有所发展或是发生改变。
从功能上看，它们都能更新和新增。 怎么才能正确的区分使用场景呢。
 |
1
murmur 2020-12-30 11:22:13 +08:00
不用分清，从经验来看，我们只做 post 和 get，跟其他人解释另外两个语义太费口水
|
|
2
murmur 2020-12-30 11:23:29 +08:00
甚至我们都不会一个接口做两个语义，语义化挺好，但是给别人解释和说明语义，以及跟不看文档的人联调踩坑太多
还不如一个接口唯一用途，post 的接口数据少你拿 get 传我们也认，反之亦然 |
 |
3
TabGre 2020-12-30 11:23:36 +08:00 via iPhone  2
鄙司后台：不用问，全是 post
|
 |
4
baiyi 2020-12-30 11:23:43 +08:00 2
幂等性，POST 不幂等，PUT 幂等
|
 |
5
wysnylc 2020-12-30 11:32:07 +08:00
一个接口同时有多种操作,此时你用什么都是无法完全概括的
写业务已经很费劲了还要去声明这个接口是 XX 属性只能 XX 操作,我看你是工作不饱和 |
 |
6
sadfQED2 2020-12-30 12:10:53 +08:00 via Android
用哪个看我心情
|
 |
7
Pastsong 2020-12-30 12:25:24 +08:00
PUT 是幂等的，但在实际使用中大多场景都保证不了请求的幂等性，就连很多 GET 请求也不幂等，所以一般不用 PUT
|
 |
8
Jooooooooo 2020-12-30 12:31:52 +08:00
通通用 post 即可
|
 |
9
newtype0092 2020-12-30 12:33:58 +08:00
每次看到人讨论 RESTful 的 method 含义就像在做阅读理解。。。
|
 |
10
sinxccc 2020-12-30 12:55:20 +08:00
自己跟服务器商量好就行了…
|
 |
11
liuxey 2020-12-30 12:58:32 +08:00
做着做着，最终都是 POST 一把梭
 |
 |
12
f6x 2020-12-30 13:05:45 +08:00 1
IETF: 30 年前我们是这么设计的,blabla
RESTful: 设计很好,我们现在是这么标准化的, blabla 程序员: 什么? 只会 POST |
 |
13
est 2020-12-30 13:10:03 +08:00
RESTful 没文化
OPTIONS + POST 打天下。 |
 |
14
otakustay 2020-12-30 13:20:57 +08:00
PUT 的 URI 对应**唯一**的资源，POST 的 URI 对应资源的**集合**
|
 |
15
ai277014717 2020-12-30 13:22:01 +08:00
put by id
|
 |
16
Leonard 2020-12-30 13:26:05 +08:00
我是发现这些都没人用，全是 GET 和 POST
|
 |
17
hand515 2020-12-30 13:40:18 +08:00
关键你服务端 Restful 玩得再溜，每次跟客户端对接还得再解析一遍
|
 |
18
jtsai 2020-12-30 13:43:39 +08:00 via iPhone
语义不同
|
 |
20
icew4y 2020-12-30 14:00:16 +08:00 via iPhone 1
restful 把简单的事情复杂化了
|
 |
21
imgbed 2020-12-30 14:18:56 +08:00
API 的话，我全部用 POST，好像没什么问题
|
 |
22
imdong 2020-12-30 14:27:07 +08:00
目前也就 post get delete，容易识别的。
写 post 读 get 删 delete 其他得不解释，而且使用 delete 之前还特意和客户端沟通说没问题。 |
 |
23
charlie21 2020-12-30 14:28:22 +08:00 via iPhone
用 PUT 也可以没幂等性
|
 |
24
litchinn 2020-12-30 14:32:31 +08:00
我理解的 Restful 是面向资源的，在 restful 中不应该使用`/user/add`等，所以 CRUD 对应的 URI 只有一个，例如`/user`，你新增都已经把 POST 用了，修改自然只能 PUT 了
|
 |
25
tinyRat 2020-12-30 14:35:23 +08:00
看似前后端分离，接口用 post 梭哈。
|
 |
26
leafre 2020-12-30 14:55:16 +08:00
都用 post
|
 |
27
falcon05 2020-12-30 14:59:12 +08:00 via iPhone
restful 在实际应用各种变形，算了，post 一把梭
|
 |
28
anmie 2020-12-30 15:41:17 +08:00 2
get：从服务器获取数据
post：向服务器增加数据 put：修改服务器已有数据 del：删除服务器已有数据 |
 |
29
draguo 2020-12-30 17:38:50 +08:00
restful 看着很美好，实际使用不如都 post 方便
|
 |
30
strongcoder 2020-12-30 21:02:43 +08:00 via iPhone
全部都用 post
|
 |
31
tonyaiken 2020-12-31 00:40:58 +08:00 via iPhone
我们公司是严格按照语义的，内部也有指南。同事不按指南定义会被打回的。
|
 |
32
xmumiffy 2020-12-31 02:17:07 +08:00 via Android
put 和 patch 才有语意的近似，put 全量修改，patch 部分修改。
至于 post 和 put，你把 post 当修改，那你用什么做新增？ |
 |
33
ghostsf 2020-12-31 08:41:01 +08:00 via iPhone
严格按 restful 执行还是香的
|
|
34
baiyi 2020-12-31 09:07:13 +08:00
@Pastsong #7 GET 是安全的，所以一定是幂等的，绝大多数 GET 都应该是安全的操作
在我的理解中，幂等不代表每次请求的响应内容相等，而是指重复一个请求对服务造成的后果是相等的。简言之就是这个请求是可以重试的。 |
 |
36
h82258652 2020-12-31 09:50:41 +08:00
GET 只读，幂等
POST 新增，不幂等 DELETE 删除，幂等 PUT 修改，幂等 其它没法分的通通都扔到 POST 里，例如 Login 、SendEmail 这种的。 PATCH 基本不用，因为 PATCH json 处理起来稍微麻烦点。 |
|
37
baiyi 2020-12-31 10:25:48 +08:00
@bsg1992 #35 这个“对服务造成的后果是相等的“是基于业务逻辑的。
用 Github starred 请求来举例，这个操作就是典型的 PUT 操作，因为你对一个仓库请求 N 次，业务逻辑也都是 starred 。想要取消，需要请求 DELETE 方法的 starred 接口。 假如 Github 不按照上面的业务逻辑设计，而是改为“你对一个 starred 仓库再次请求，会取消 star”。基于这个业务逻辑，starred 接口就要设计为 POST 。 但可能我重试了 N 次之后，N+1 次被服务器拦截了，它认为我是恶意攻击，这与业务逻辑无关，只是从安全性上考虑，也与 HTTP method 语义无关。 |
 |
38
julyclyde 2020-12-31 16:16:01 +08:00
POST 的那个网址一般是个程序
PUT 的一般是要上传的内容将来的名字 |
Select Language