Ask HN: What style for an image-resizing service?

> 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.

It 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).

If 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.

> 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.

This 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/

    https://imgk.io/rs?s=http://external.com/images/dog.jpg&w=600

Thanks 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.