我想为网站抓取服务设计RESTful API。用户将任务委托给服务。每个任务都是必须转义的网站。用户可以检查任务的状态。完成任务后，用户可以获取任务结果。 完成后，状态可以是“正在等待”，“进行中”或“完成”。用户可以获取数据。
我现在拥有的是：
POST /tasks-发布要抓取的网址
GET /tasks-返回任务列表
我还需要两个端点：一个用于获取任务状态，另一个用于从网站获取抓取的数据。 GET应该是什么样子？
GET /tasks/{id}-返回状态？还是返回数据？或者也许
GET /tasks/{id}/status GET /tasks/{id}/data 但是接下来会返回/tasks/{id}/的是什么
如果我还想将已封装的数据显示为html怎么办？ 我应该使用
GET /tasks/{id}/data或GET /tasks/{id}/result 答案 0 :(得分：0)
我真的不知道约束，但是GET / tasks / {id}可以同时返回状态和数据。
如果您不愿意这样做（例如，如果从性能的角度来看，频繁获取数据会成为一个问题），那么似乎明智的做法是：
GET /tasks/{id} @returns status and other plain task fields
然后：
GET /tasks/{id}/scrappeddata @returns data
为什么？因为，这种方式可能与您的模型（和/或您的API用户所想到的心理模型）最一致。
Rest API教程中给出的有关资源命名的一般规则会有所帮助：https://www.restapitutorial.com/lessons/restfulresourcenaming.html
答案 1 :(得分：0)
POST /tasks - post a URL to scrape
GET /tasks - returns a list of tasks
那很好。请注意，当您成功POST时，缓存失效就会开始。通用客户端将知道先前返回的任务列表的表示形式不再有效。
GET /tasks/{id} - return a status? Or return the data?
为什么两者都不一样？ /tasks/{id}标识资源；您可以使用任何喜欢的表示形式。该表示没有理由不应该包含可选元素。
（令人毛骨悚然：网页会是什么样？您真的觉得需要为这个概念提供两个不同的我们页面吗？如果没有，那么它可能只是一个资源在您的API中。）
如果我还想以HTML形式显示已封装的数据怎么办？
相同的标识符适用于多种表示形式；客户端可以使用Accept标头来描述其对服务器的偏好。
您可能需要考虑客户如何知道可能的表示形式的问题。在Web上，HTML规范描述了许多不同类型的链接-例如，浏览器遇到脚本标签或图像标签时可以声明不同的首选项。您将需要自己的媒体类型中的相似内容。
确定这些都应该是不同的资源也没有错。两种方法都可以采用与REST体系结构风格一致的方式来实现。
答案 2 :(得分：-1)
在为RESTFUL api命名路由时没有硬性规定。 您可以遵循约定，了解最佳实践，并从SO中获得建议，但是最终，您是设计API的人，因此您比其他人更清楚适合自己的特定用例的东西。
搜索“ rest api命名最佳做法”或“如何构建rest api路线”，您将获得很多想法。
我和@jonrsharpe提出的2条建议都是有效的，由您决定什么对您的项目有意义。