RESTful 设计的具体场景问题.

Question

假设有这么一个后台管理页面:

id	name	age	status	action
1	张三	18	P	edit/delete
2	李四	17	A	edit/delete
3	王五	16	S	edit/delete

其中除 ID 栏外,每一个格子都可以直接点击编辑. 比如点击张三,切换为输入框,输入新 name, 鼠标失去焦点,保存改变后的值.

action 栏中的 edit,点击之后跳到 编辑页, 修改所有的信息.

采用 JWT 模式开发. 那么 edit 部分的 API 应该如何设计?

第一种

1. PUT /v1/person/name
2. PUT /v1/person/age
3. PUT /v1/person/status
4. PUT /v1/person

第二种

1. PUT /v1/person 只提供一个 API,这个 API 处理所有情况,不管是单独的字段还是所有的字段更新

第三种

1. PUT /v1/person/status
2. PUT /v1/person

提供一个更新所有的字段的 API, 但是如果更新 status 逻辑过于复杂,则把 更新 status 单独抽离,其他的字段单独更新走第二个.

这里我们假设,更新 age/name 不会触发复杂的业务逻辑,但是status 如果变化会触发非常复杂的业务逻辑

应该如何设计 API.

Answer 1

实际上，多数情况下，使用第二种形式，否则api接口会太多。

Answer 2

不要要特殊权限的就放一起，如果status要单独权限的话就新加一个接口， 其他就PUT /v1/person:id就行了

Answer 3

建议你只提供一个接口 PUT /v1/person/:id，这个接口内部再根据不同的数据变化来进行分别的处理，如果内部逻辑太复杂，可以用 OO 思想和设计模式继续拆，但与外部的接口无关。

另外，理论上来说，一般不会直接去更新 status，而是由于更新了某些其他数据，或者由于其他业务，引起 status 在业务内变化。当然这跟业务逻辑设计有关。你现在这种设计，感觉比较像是通过 status 变化来触发业务过程。

Answer 4

更新不同数据能和业务完全解耦吗？API 应该如何设计?
业务上有一个submission流程，可以create，update，resubmit，
表A：

id	image_uuids	album_id	status_id
1	js2323	18	P
2	d23zsd	17	A
3	se34sf	16	S

表B：

id	submission_id	publication_name	publication_user_id
1	23123	blue	23
2	4134	pink	44
3	53422	yellow	444

1. update业务流程：对数据来说，只是更新 表A 的 image_uuids
2. resubmit流程：只是更新 表B 的 publication 和 status_id 字段，并且发邮件
3. 更新status字段（不在submission这个业务流程里面），额外的template

API都用 PUT /v1/submission/{id} 这种吗？
初进入API设计，求大神们指点

@边城

Answer 5

第二种
不管你的/v1/person有什么字段，有多么复杂， 客户端只关心

{
    "name":"xxx",
    "age": 18,
    "status":0
}

这个结构

Answer 6

GET /zoos/ID/animals：列出某个指定动物园的所有动物

我有个疑问,对于这种 url , 为什么不采用 GET /animals?zoos={id} 方式呢? @边城