我开发了一个非常小的 REST API（使用 PHP），它提供有关用户的信息（也更新和创建用户，但对问题无关紧要）。只是为了显示可用的调用（顺便说一下，JSON 输出）：
/api/users/54216
/api/users/54216?fields=id,name
/api/users/54216/photos
54216是一个示例用户 ID。
直到今天，我只使用缓存来保存要显示的 html 页面，实际上并不复杂 - 从未使用缓存来仅保存数据。
我应该怎么做才能保存这些电话，然后我该如何使用它？我的目标是（我认为..）在 X 分钟内将数据保存到JSON文件一次，并在需要时获取文件缓存和decode它。
另外，你建议我如何缓存用户的特定信息？因为调用 no.1 输出所有信息，调用 no.2 只输出特定字段，我不想使用 2 个缓存文件，因为它真的没有效果。
我从来没有参与过这个部分（缓存[json]数据和REST API，这是我的第一次），所以我很困惑。
编辑：
我说的是服务器端缓存。
我建议你阅读HTTP Cache
第一个重要的原则是了解 HTTP 缓存是如何工作的，基本上有两部分，TTL（缓存控制）和过时检查（ETag）。当源服务器生成资源时，您需要考虑它已经消失了。您不再可以控制它，您只能向客户提出如何处理它的建议。您拥有的两种机制是 TTL（即客户端在返回之前应将对象保留在缓存中的时间）和过时检查（这是返回的资源的版本），它们可以与新的 GET 请求一起发送到源服务器，说“嘿，我有这个版本还不错”。让 Origin 服务器有机会说是的，继续使用该服务器并提供一个新的 TTL，如果它仍然有效的话。
您需要以不同的方式使用这两个控件来获得您想要的效果。例如，在提供永远不会更改的文件时（例如用于构建的 css），您可以设置一个非常长的 TTL，并且没有 etag。对于不经常更改但需要快速更改的内容（例如预订中的派对成员），您可以设置较低的 TTL（例如 1 分钟）和 ETag。在第二个示例中，您将 TTL 设置为 1 分钟，以帮助处理来自客户端的突发事件，以免淹没原始服务器（规模），并且 ETag 允许原始服务器跳过保留对象的构建，如果它有验证方法当前有效的 ETag 比构建整个预留要快。另一个例子是不经常改变的东西，当它改变时，它可以缓慢传播（就像用户的广告推荐配置文件一样）您可以设置更高的 TTL（例如 6 小时），而不必太担心 ETag（尽管它仍然很有用）。参考：https://groups.google.com/d/msg/api-craft/YJMH0XMQJIM/HtdAPEXbQLMJ
或者，如果您想在服务器端缓存，请查看 memcached（教程）
并查看反向代理缓存解决方案，如清漆等。
https://devcenter.heroku.com/articles/ios-network-caching-http-headers
这从 iOS 的角度解释了缓存，但是对术语 Cache-Control、max-age、ETags、Last Modified 进行了很好的解释。