通过REST API提供多种图像分辨率

Question

我们正在开发一个REST API，用作我们的iOS和Android应用程序以及AngularJS Web应用程序的后端。为了优化性能，我们必须提供各种分辨率的图像。我正在寻找有关如何为客户端提供适合其设备分辨率的正确图像URL的指南。我可以想象三种可能性：

1.客户端具有确定图像的分辨率相关URL的逻辑。
REST API返回规范的图像URL：

{
   "user": {
      "id": 1,
      "image_profile": "https://cdn.mydomain.com/abcd.jpg"
   }
}

然后，客户端知道如何更改URL以获得所需的分辨率。
例如：https://cdn.mydomain.com/abcd@2x.jpg或https://cdn.mydomain.com/w_100,h_100/abcd.jpg。

这是基于这样的想法，即客户端可以准确知道图像的去向以及所需的大小和分辨率。缺点是客户端上的逻辑更多。例如，可以使用诸如http://cloudinary.com/的服务来实现。

2.服务器为每个映像提供不同的版本。
REST API返回所有可用的图像URL：

{
   "user": {
      "id": 1,
      "image_profile": {
         "url": "https://cdn.mydomain.com/abcd.jpg",
         "versions": {
            "mhdpi": "https://cdn.mydomain.com/abcd_mhdpi.jpg",
            "lhdpi": "https://cdn.mydomain.com/abcd_lhdpi.jpg",
            "2x": "https://cdn.mydomain.com/abcd@2x.jpg",
            "web": "https://cdn.mydomain.com/abcd_web.jpg"
         }
      }
   }
}

在此解决方案中，客户端需要较少的逻辑，并且调整图像大小的实现与客户端无关。响应变得有点污染。

3.服务器根据用户代理（或任何其他参数）自动返回正确的图像
客户端可以在用户代理标头中指定其预期的分辨率（或可以?resolution=2x向每个请求添加类似的内容。
例如iPhone 5S (iOS 7.1)，API的用户代理）会自动返回正确的图像：

{
   "user": {
      "id": 1,
      "image_profile": "https://cdn.mydomain.com/abcd@2x.jpg"
   }
}

客户端忽略了分辨率问题，但是这种方法使响应的可缓存性降低，并且感觉最像魔术。

您能否建议其他解决方案，详细介绍所提出的解决方案的优缺点，并为我提供一些有关知名API如何处理此问题的资源？

Answer 1

第二种选择最适合RESTful API设计，并具有其固有的优势。

依次轮流：

1.如果您出于任何原因需要更改图像标识符URL格式，则更改URL的客户端可能会破坏客户端。

2.服务器提供的多个版本最好与RESTful方法保持一致，其主要好处是更改URL格式不会破坏现有客户端。它还允许可扩展性，它可能是自我描述的，并且是机器可读的（变化很小），如下所示：

{
   "user": {
      "id": 1,
      "image_profile": {
         "url": "https://cdn.mydomain.com/abcd.jpg",
         "versions": {
            "100": "https://cdn.mydomain.com/abcd_mhdpi.jpg",
            "150": "https://cdn.mydomain.com/abcd_lhdpi.jpg",
            "300": "https://cdn.mydomain.com/abcd@2x.jpg",
            "72": "https://cdn.mydomain.com/abcd_web.jpg"
         }
      }
   }
}

...即您可以将标识符重新定义为“ DPI”数字或类似名称。我不知道您的客户端应用程序有多高级。但是他们可能会寻找DPI的数字“最近匹配项”，以符合使用中的屏幕尺寸。然后，您可以在将来相应地插入其他分辨率。

3.服务器使用代理字符串可避免选项1的风险；但是客户端应用程序本身最好决定解决方案，因为它对上下文有更多了解。

摘要

选项2不以任何方式限制您；并且对于避免将来发生重大变化也是最有弹性的。