这取决于您在设计的rest服务中如何定义数据模型，以及您提供的功能。
我的第一个想法是将事物分开，将track info定义为由其元数据定义的主要资源，而将其他所有内容定义为子资源。您的端点可以按如下方式设计： POST /audiotracks ：创建音频曲目资源。元数据是资源的内容，很可能是json格式。 POST /audiotracks/{trackId}/albumcover ：以base64编码字符串形式发布相册封面文件。 POST /audiotracks/{trackId}/content ：以base64编码字符串的形式发布曲目内容。 GET /audiotracks/{trackId} ：获取音频曲目元数据。 GET /audiotracks/{trackId}/albumcover ：取唱片封面。 GET /audiotracks/{trackId}/content ：获取曲目内容。
等

最终的解决方案与api的使用方式和业务运作方式密切相关。当然，无论如何都可以使用很多解决方案，但其中一种会比其他解决方案更有效。
一种灵活的方法可以是定义 Track 具有crud操作的实体，其中 Update 将允许两种模式 PUT 更新整个内容（例如，如果请求中没有声音，则会将其删除），以及 PATCH 部分更新。
您的api定义或多或少可以遵循（以rest方式）： POST /track 创建一个新的单曲，请求可能包含也可能不包含所有信息。
DELETE /track/{id} PUT /track/{id} 更新所有曲目信息（与 DELETE 及 POST 再说一次，但是 {id} 保留）。 PATCH /track/{id} 更新曲目信息，没有提供的信息将不会被删除。 GET /track/{id} 返回整个模型。 GET /track/{id}/projectionX 哪里 projectionX 您是否需要任何查询/投影（仅音频、仅一般信息、合成/编码音频）
但是，如果在您的业务中，一个唱片封面将被多个曲目重用，那么您应该以类似的方式定义这个新实体，并更改 Track model to只包含对“相册封面”的引用（而不是图像本身）。
通过这种方式，您可以重构所有实体，只需进行最小的更改（只有模型而不是api调用工作流）。
e、 g.如果你定义 /audiotracks/{trackId}/albumcover 数据模型关系的更改（例如，添加 Album 实体）不仅必须更改所有数据模型，还必须更改api调用和工作流。
无论如何，只有在新的业务需求下才能开发api。