适当的数据导出设计

2022-10-11 01:12:41标签apirestarchitecture
提问

剩下的最合适的方法是导出什么东西作为PDF或其他文档类型? 下一个例子解释了我的问题: 我有一个叫香蕉的资源。 我为该资源创建了所有标准的CRUD rest端点(即GET /香蕉;GET /香蕉/ { id };POST /香蕉/ { id };…) 现在我需要创建一个端点,它下载一个文件(PDF CSV 。),它包含所有香蕉的表示。 首先,我想到的是GET /香蕉/出口,但在纯粹的休息中使用url中的动词是不允许的。使用更恰当的httpMethod可能会像出口/香蕉这样的东西,但不幸的是,这还没有(可能)。 最后,我考虑使用基于不同媒体类型的相同GET /香蕉端点的Accept头(应用/ json应用/ pdf 。)返回数据的相应表示(json pdf 。),但我不确定是否用这种方式误用了Accept头。 有什么想法吗? 在纯粹的休息中使用url中的动词是不允许的。 REST不关心您在资源标识符中使用的拼写习惯。 示例:https://www。merriam-webster。com/dictionary/post 即使“post”是一个动词(更糟的是HTTP方法令牌!)URI就像web上的其他资源标识符一样。 从REST的角度来看,更有趣的问题是,在其他上下文或不同的情况下,标识符是否应该相同。 REST关心的是缓存(这对使web“web scale”非常重要)。在HTTP缓存中,主要是重新使用先前的响应。 基本的(但不完整的)想法是,我们可能能够重新使用与相同的目标URI相同的响应。 HTTP还建立了一个通用的机制,用于使存储在目标URI上的存储响应失效。 所以,这是你需要思考的一个谜题的一部分:当有人向/香蕉发送POST请求时,缓存会把先前的响应与PDF陈述分开吗? 如果答案是“不”,那么你需要一个不同的目标URI。这对你来说是有意义的。例如,pdfs /香蕉。(在标识符中使用了多少条路径段,这取决于您从相对引用和点段中实现的方便程度。) 如果答案是“是”,那么你可能想要倾向于使用内容谈判。 在某些情况下,答案可能是“两者”——也就是说,有多个资源(每个都有自己的标识符),返回相同的表示。 这是一件很正常的事情;我们甚至有一个机制来描述哪些资源是“首选的”(参见< href = ' https://www。rfc编辑。org/rfc/rfc6596。html”rel =“nofollow noreferrer”> RFC 6596 < / a >)。 媒体类型是表示这一点的最好方法,但这其中有一个实用的方面,人们会使用词根名词浏览rest API……我会给它写一些记录,可能会得到/香蕉/出口/ 100,得到第一个100,如果他们真的想要所有的东西,就得到/香蕉/出口/所有。

回答

回答

▼版权说明

相关文章也很精彩
推荐内容
更多标签
相关热门
全站排行
随便看看

错说cuoshuo.com——程序员的报错记录

部分内容根据CC版权协议转载,如果您希望取消转载请发送邮件到cuoshuo8@163.com

辽ICP备19011660号-5