我正在开发 CMS，我正在尝试找出执行 REST 样式图像请求的常见做法。我有三种尺寸，小号、中号和全号。我的想法是只存储完整的并编写一个函数来调整每个页面请求的大小。这有明显的cpu成本。另一端是我可以存储所有三种尺寸，只在上传时计算，这似乎浪费空间。
我的环境是内网，所以请求相对较少，存储的图像数量较多。想法？
注意：我意识到我不必太担心，因为它是 Intranet，任何一种解决方案都可以工作，只是想知道为了知识起见，哪个更适合。
【问题讨论】：
标签： c# asp.net-mvc-3 content-management-system storage
另一种选择是维护调整大小图像的缓存。提供可用的。如果它们不可用，请创建新的。删除一段时间未请求的图像。
这将是 CPU 和存储问题之间的妥协。
【讨论】：
存储完整的然后根据需要生成其他大小并缓存它们；页面处理在第一次请求时会稍微变慢，但缓存的版本将用于所有后续请求。
【讨论】：
由于您认为存储的图像很多而请求不多，所以我会采用 resize-on-the-fly 解决方案，因为听起来您已经知道存储空间会成为更大的问题。
如果您想变得花哨，您可以为 n 设置一个 MRU（最近使用的）缓存 - 最常请求调整大小的图像，但同样，如果请求数量较少，这可能会矫枉过正 - 但仍然可能是一个有趣的项目！ ;)
【讨论】：
REST 的一个关键点和标准 HTTP 动词的用法是它支持缓存；我认为这将支持进行动态调整大小的意图。不过，这实际上是一个权衡存储空间与请求时间计算的问题。
【讨论】：
如果系统负载不是问题（假设是低容量的 Intranet 应用程序），我会存储全尺寸图像并在运行时对其进行缩放。这样，如果您需要其他尺寸，则无需替换所有图片。
但正如您上面所说，了解权衡并对系统负载、磁盘空间、需求变化的可能性等做出一些良好的估计。
【讨论】：
您自己回答了这个问题，这是 CPU 空间的权衡。 您知道每条路径的成本，只需问问自己，哪种资源对您来说成本更高。
【讨论】：