我正在尝试创建一个遵循最佳实践，直观的API，并且与开发人员从其他（设计良好的）API中看到的模式匹配。我相信我了解HTTP动词对典型资源的各种映射，这与这两个问题的答案一致：
哪种HTTP方法与哪种crud方法匹配？
理解休息：动词，错误代码和身份验证
我遇到麻烦的地方是，由于我们的业务性质和检索数据所需的数据，这通常是一个get，我们需要使用帖子。这是由于请求的大小以及我们要进行搜索的内容。
您什么时候使用帖子，什么时候使用？
所以，我可以想到一些关于如何最好地处理CRUD的方法，我很喜欢一些建议：
- 使用帖子中的查询参数来区分创建vs读，其他动词正常。不喜欢这个主意。
- 每个动作都有一个单独的终点，例如/baseurl/lookup，/baseurl/create。不遵循使用名词而不是动词的正确模式。
编辑：为了清楚起见，在我对图像查找服务的评论中，人为的示例，在该服务中，呼叫者可以在数据库中搜索图像，请添加新映像，更新图像（例如添加元数据）或删除图像。
创建： 我们应该在这里做什么？发布/映像/创建并更新读取端点为/image/search？
阅读： post/image {imagedata = somebase64encodedImage}
更新： put/image/{imageId}
delete： delete/image/{imageId}
我认为使用POST来检索资源存在误解。从高度角度来看，您可以说一个问题如下：
我需要从匹配许多参数的服务器中检索一个实体列表。我该如何实现？
因此，将POST视为请求读取的平均值的温度很强。同时，也是误导性的。您在任何地方都在听到息息的传教士发誓要通过GET实施阅读，并使用POST进行隧道操作是REST Antipattern 。。
解决问题的解决方案非常简单，这是关于改变我们的方法。它不是阅读的POST。这是关于向服务器提交请求票，等待回复。而且，实际上，使用POST绝对是我们正在做的事情。 POST，创建 subresource ，ofere（是的，它也可以用于更新，但我不想迷失详细信息）。
因此，如果您想查询服务器中的复杂资源，只需放置票证并等待响应即可。让我们检查一个用例：
您有以下URI
标识的car资源 http://authority/api/cars/{id}
，例如，您想通过发出POST来以非常复杂的方式查询服务器。
您将使用什么端点？绝对不能选择
POST http://authority/api/cars
，因为如果您这样做，您期望获得的只是制造汽车，不是吗？解决方案再次非常简单。您正在尝试将查询票提交给连续机票，因此您应该决定此资源。您可能会更具创造力，但也许这可以起作用
POST http://authority/api/tickets/cars
POST查询票证到该端点的查询票，您可以期望使用location标头返回响应，涉及与您的请求匹配的汽车列表（CARS资源）（状态代码201 = CRETED或202 =接受，结果将尽快准备就绪）。如果计算足够快，将结果包括在HTTP响应中不是致命的罪（个人意见）。
有关更全面的论文，请参阅此精彩文章：如何喝杯咖啡。