Should a few KB images in the API (such as user avatars) be put into the JSON stream?

Rt
What should be done with the trivial and small number of KB images in the design client-server interaction API?

• How do you design the caching mechanism for these small images in the client?
• How do I handle the location of these small images on the server?
• What about those small pictures (size 10+kb)?

Reply content:

Rt
What should be done with the trivial and small number of KB images in the design client-server interaction API?

• How do you design the caching mechanism for these small images in the client?
• How do I handle the location of these small images on the server?
• What about those small pictures (size 10+kb)?

JSON stream?

Do you mean to pass those pictures directly to the client after Base64 encodeing processing through the JSON API?

If this is the case, then there are both advantages and disadvantages, a few questions for you to briefly say:

1. Generally trivial a few KB of pictures can be encoded after transmission will be faster, of course, if the volume is not up, the difference is very small

2. Unfortunately, if you are not directly requesting binary files, the Data URI is not cached on the client, and they must be re-downloaded whenever the document changes

3. Whether it's the same size or not, it might involve disk read and write performance. I don't know much about that.

4. The ... How do you define this? Is it necessary to design a system for the size and size of the picture in the next three files? I think the static resources to do a CDN processing, the API back to request the CDN address to the client is good, the most mature practice is the case. As for those particularly small things, generally are icons or the like, or sprites processing, or directly into the font.

Do not use Base64 more than 200 bytes. Please believe the power of gzip.
Please be assured that the volume after binary serialization is about twice times larger than the binary.

