3 ms·
Ask HN: What style for an image-resizing service?
I'm building an image-resizing service (long story).
I was wondering what style is better for the URL-based API. If your image is https://example.com/images/logo/test.jpg, which one is better:
https://app.imagekick.io/example-com/images/logo/test.jpg/resize/500x/flip/hoz/
https://example-com.imagekick.io/images/logo/test.jpg/resize/500x/flip/hoz/ (can be CNAMEd to images.example.com)
https://imgk.io/example-com/?src=/images/logo/test.jpg&width=500&flip=hoz
Passing the image as a GET parameter makes it easier to import external images:
https://imgk.io/example-com/?src=http://external.com/images/dog.jpg&width=600 versus https://app.imagekick.io/2y789/fetch/http%3A%2F%2Fexternal.com%2Fimages%2Fdog.jpg/resize/600x/
What do you guys think..? I personally like the URL-based solution because it's somewhat quicker to type, and the operations can be chained. Passing instructions as GET parameters makes it easier to specify external images.
- franze 10y agohttps://imgk.io/rs?s=http://external.com/images/dog.jpg&w=600
- nkkollaw 10y agoThanks for your feedback! So you're saying the shorter, the better? I wonder if there's any value in chaining transformations, it's kind of cool though.
- koliber 10y agoIf you want to import external images, I would lean towards preserving the URL. Therefore, a GET param for the image. Also, what if the URL of the image has the word "500x" or "resize" in it? The non-GET-param solutions make me think too much: 1. Take the domain, and change any dots to dashes. What if there's a subdomain, or three levels of subdomains? 2. Add the domain as a subdomain on imagekick.io 3. Take the rest of the URL and add it as the path 4. Add the transformations on top of it The transformation instructions can still be passed as part of the path, or as a GET param. Heck, support both.
- nkkollaw 10y ago> Also, what if the URL of the image has the word "500x" or "resize" in it? I'm supporting images that end in .jpg, .png, or .gif. So currently I know that anything after the extension is parameters. > 1. Take the domain, and change any dots to dashes. What if there's a subdomain, or three levels of subdomains? 2. Add the domain as a subdomain on imagekick.io 3. Take the rest of the URL and add it as the path 4. Add the transformations on top of it The rationale was that to create a resize/manipulation URL you only had to change the domain. For instance: //example.com/image/dog.jpg becomes: whateveryouchooseassubdomain.imagekick.io/image/dog.jpg Also, if you don't add parameters the image is served via a CDN, so potentially one could use this just to easily add a CDN to his images. > Heck, support both. Yes, I thought about that as well. It could be kind of confusing to explain, though. I'd rather pick the best way and just do that.
- KenCochrane 10y ago> I'm supporting images that end in .jpg, .png, or .gif. So currently I know that anything after the extension is parameters. How do you know that is the extension and not a directory with a .jpg in the name? It is too complicated to convert to your URL scheme. For me the URL based solution isn't quicker to type since I have to think too much. Also, how often is this going to be typed by hand verse scripted anyway? It will be easier to script if the URL is the same and only the GET Params change. I prefer the get parameters, it is more obvious. Another option that isn't as clean, but I have seen before is to Base64 encode the image URL. You wouldn't be able to easily type but you could keep your URL scheme, and still possible to script.
- nkkollaw 10y agoIt looks like most people like the GET parameters approach, so I guess it makes sense to just opt for that. I seem to be alone in caring if it looks good or not (rightfully).
- KenCochrane 10y agoThis project looks pretty popular and they are using a URL based API, maybe you can copy their URL structure. http://thumbor.readthedocs.io/en/latest/ http://thumbor.readthedocs.io/en/latest/