面向移动客户端的RESTful Api

Question

我是移动开发者，总是和我的web服务/后端开发者有一个特别的斗争，他们相信设计restful。

问题:根据Restful设计，每个api在本质上都应该是原子的，但是这会给客户端带来很多问题，特别是基于移动的。因为要执行像打开特定页面这样的任何操作，我可能需要进行N个调用来加载数据，这会给用户带来非常糟糕的体验。

一个有效的用例来解释:在电子商务应用程序中，加载一个产品详细信息页面.在本页面中，我们必须显示产品详细信息、库存信息、提供描述、相关产品、推荐产品等，根据restFul，每个产品都可以是一个单独的api，单独加载每个api都会扼杀用户体验，进行聚合调用是违反Restful主体的。

有人能告诉我你是如何解决这个问题的吗？

Answer 1

需要提醒后端开发人员的是: REST没有提到有效负载中对象的大小/复杂性，只提到事务的原子性和无状态性。使用表单/product/{id}/details的路径是完全允许的，该路径返回根植于与/product/{id}相同的对象中的有效负载，但附加信息可能从多个表中提取。如果对可选的附加信息有复杂的需求，则可以使用简单到表示变体的路径，也可以使用查询字符串变量。在PUT方面，PUT to /products/{id}可以基于此查看负载和更新表中的内容，或者只能更新基本产品，并需要额外的路径段和/或查询字符串变量来匹配相应的GET来更新附加表。选择取决于什么使应用程序的事情变得最简单、最简单/最容易理解。

这样的内部API的存在是为了达到某种目的。如果使用它会使事情变得更难，而不是更容易，这是一个明确的迹象，某些地方是不对的API。

Answer 2

API的工作是提供外部系统对信息的访问。REST建议将数据建模到资源中，并就如何使用这些模型提出建议。在编写良好的API中，构建资源是为了使客户端的工作尽可能容易。在公共API中，这是很难的。在私有API中，这要容易得多。

听起来像是在试图在单个内部客户上强制使用通用API。允许一个GET /product-details/{id}是没有错的。将其作为产品的链接(更可取)，或者为product和product-details使用相同的ID。该资源可以准确地保存产品详细信息页所需的信息。如果用户决定更新产品，客户端可以调用GET /products/{id}获取详细信息，然后调用PUT /products/{id}进行更新。