我正在尝试创建一个遵循REST最佳实践的API，直观，并且匹配开发人员从其他（精心设计的）API看到的模式。我相信我理解HTTP动词与典型资源的各种映射，这与这两个问题的答案一致：
Which HTTP methods match up to which CRUD methods?
Understanding REST: Verbs, error codes, and authentication
我遇到麻烦的是，由于我们的业务性质和检索数据所需的数据（通常是GET），我们需要使用POST。这是由于请求的大小以及我们为了进行搜索而传递的内容。
When do you use POST and when do you use GET?
所以，我可以想到如何最好地处理CRUD的几种方法，我喜欢一些建议：
编辑：为了清晰起见，在我对图片查询服务的评论中设计的例子，其中调用者可以搜索图像是否已经在数据库中，添加新图像，更新图像（例如添加元数据），或删除图像。
创建： 我们应该在这做什么？ POST / image /创建并将Read端点更新为/ image / search？
阅读： POST / image {imageData = someBase64EncodedImage}
更新： PUT / image / {imageId}
删除： DELETE / image / {imageId}
答案 0 :(得分：1)
我认为使用POST检索资源存在误解。
从高处来看，您说的问题如下：
我需要从服务器中检索与许多参数匹配的实体列表。我怎样才能做到这一点？
因此，将POST视为请求READ的意思的诱惑力很强。而且，与此同时，也是误导。在任何地方，您都会听到REST福音传播者发誓说应该通过GET实现READ，使用POST进行隧道操作是REST 反模式。
问题的解决方案非常简单，而且它改变了我们的方法。它不是POST用于阅读。它是关于向服务器提交请求票据，等待回复的响应。事实上，使用POST肯定是我们正在做的事情。 POST， 创建子资源，期间（是的，它也可用于更新，但我不想迷失在细节中） ）。
因此，如果要查询服务器以查找复杂资源，只需放置票证并等待响应即可。让我们来看一个用例：
您拥有由以下URI标识的car资源
http://authority/api/cars/{id}
并且，例如，您希望通过发出POST以非常复杂的方式查询服务器。
您将使用什么端点？绝对不能用
POST http://authority/api/cars
因为如果你这样做，你期望获得的只不过是汽车创造，不是吗？解决方案再次非常简单。您正在尝试向服务器提交查询票证，因此您应该设计此资源。你可能会更有创意，但也许这可以起作用
POST http://authority/api/tickets/cars
POST查询票证到此终端，您可以获得一个回复，其中location标题引用与您的请求匹配的汽车列表（汽车资源）（状态代码201） = creted或202 =接受，结果将尽快准备好）。如果计算速度足够快，那么将结果包含在HTTP响应（个人意见）中并不是致命的罪。
有关更全面的论文，请参阅这篇精彩的文章：How to GET a Cup of Coffee。