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