我正在尝试实现一个宁静的API
我有一个名为Program的实体（描述和位置详细信息）
我有一个称为“计时”的实体（“程序+开始时间+结束时间”
我有一个称为“签到”（时间+用户详细信息）的实体
场景： 我需要“入住时间”，
POST请求的理想网址应该是什么， 选项A
POST /programme/:id/timing/:id/check-in
query param: null
选项B
POST /check-in
request body: {programme=id,timing:id}
第一种方法将完全使用path参数中的id并直接标识资源 在第二种方法中，消费者告诉资源的类型，在过滤条件中提到 资源的类型。
注意：我们将UUID用于“程序和计时”资源，这会使URL稍大
答案 0 :(得分：2)
两者都可以，但是GET更适合于请求信息。只要您的网址少于4000个字节，就不会有问题。
答案 1 :(得分：2)
如果您要使用Restful方式，那么您要确定适当的资源并对这些资源进行CRUD操作。
有3种资源： -程序 -用户 -Schedule（时间安排对此是错误的资源名称）->属于->程序 -注册->属于（用户，时间表）
所以要注册，我宁静的端点看起来像
POST /注册 身体{user_id：user1，schedule_id：s1}
答案 2 :(得分：0)
Caching中的资源表示形式是REST体系结构样式中的重要考虑因素。
用HTTP表示的方式是，如果我们收到对不安全请求（如POST）的非错误响应，则符合标准的缓存应invalidate缓存资源。 URI是缓存键，因此POST请求的target-uri标识将要收回的缓存条目。
因此，在设计协议时，我们考虑要通过操作更改哪些资源，并在进行更改时将要更改的资源的标识符用作目标。
我们GET用什么资源来查看更改的效果？那应该是变更请求的目标。
POST /check-in
request body: {programme=id,timing:id}
如果您想在客户端上查看GET /check-in，则此拼写很有意义。从您的描述来看，这似乎不太正确-听起来太粗糙了。
POST /programme/:id/timing/:id/check-in
query param: null
另一方面，这看起来可能太细了；好像有人认为，单一责任原则的正确应用是每个POST处理程序都会做一件事。
是否有check-out与check-in一起使用？如果是这样，这些请求可能会发送到同一地方
POST /programme/:id/timing/:id
action=check-in
POST /programme/:id/timing/:id
action=check-out
可能是programme而非timing是您的域的正确选择
POST /programme/:id
action=check-in&timing=:id