Sometimes we are way too harsh and pedantic on each other. Instead of trying to help each other grow, we call our fellow engineers out for making decisions we disagree with.
This service is offered for free, and new routes can likely be added without trouble. It isn't like this is a choice that actually impacts anyone. It's merely a matter of style.
The only thing terrible here is the way the criticism is being offered. So I'm offering you feedback.
I guess it is not "terrible". I think the product can be improved in the manner suggested since it's heavily reliant on typing URLs manually, and I'm curious why the current format was selected. I am not discounting the entire product just because I am commenting on a very specific part of it.
It is a great site and idea, and I think many people have already suggested that.
Common pattern for such a service. There is no 'id' in the path, that isn't how it works, you just want the one path component for the size in order to return a square image and then if you give a second path component you get the y dimension. It is as simple as that.
I'm surprised it hasn't been written this way from the start, with the url rewriting on top. I don't know much about Go but in the "good old days" we would use apache to do the http stuff, including url rewriting, and {insert moudly language here} to just use the params it was given by the web server. It didn't matter if the url was rewritten for aesthetics or it used query string params. You could even run the same script from the command line. Magic!
Nowadays it seems like the front-end languages like to get their hands dirty in the url parsing for better or for worse. Often worse IMO. The application layer should be dealing with business logic, not http transport. Again, this just my (slightly dated) opinion.
Ugly yes, over engineering? no it's what you would have done in PHP in the 90's. Doing the URL thing would need more work (hello .htaccess). Anyway...
Good points: It is semantically correct and self documenting. There is no resource called 300 nested under a resource called 200 so lets not pretend there is. The query string seems perfect for the job of providing size parameters. You can then extend this interface to take other factors you want to affect the image, and keep it backwards compatible. Function over form.
It's using the URL as it was designed. in 21323/200/300, 200 is not a sub-resource of 21323, neither is 300 a sub-resource of 200. Specifying w and k parameters to the request is semantic and engineering accurate to the intent of the user
Sometimes we are way too harsh and pedantic on each other. Instead of trying to help each other grow, we call our fellow engineers out for making decisions we disagree with.
This service is offered for free, and new routes can likely be added without trouble. It isn't like this is a choice that actually impacts anyone. It's merely a matter of style.
The only thing terrible here is the way the criticism is being offered. So I'm offering you feedback.