That's an implementation detail that doesn't make sense in the addressing scheme. Like adding "brick house" to the end of every mailing address when the destination is made of bricks.
> What about if an mp3 is at the end of a URL? Is that an implementation detail that doesn't make sense? Just take of the .mp3 extension?
Yes, why not? Just because file extensions matter to certain systems doesn't mean they do for others, and nothing about a URL to a file is required to match its DOS/Windows friendly file name.
> GET /<artistname>/<albumname>/<songname>/download HTTP/1.1
> It's nice in browser history to see foo.mp3 and know it's an mp3.
TBH I agree, I personally do my best to ensure the extension in the URL matches the document type on sites I run, but my point was that it's not in any way required and it's actually somewhat common for it to not be the case where the person I was replying to seemed to think it mattered.
Not seeing any advantage, and serious disadvantage.
The hiding of the index file name in a folder is kind of a quirk, it's automatic behavior that is being taken advantage of to make "nice" URIs, but it's actually hiding useful information.
File extensions, while a DOS/Windows thing, I've found to be an extremely useful convention on unix, and linux, and just about any other system I've used (though I can't remember what we did on VAX box we used to use in the 90s).
If the extension is there because that's what the file is on the server, that's wrong. If the extension is there because the endpoint will return that type of content, I'm fine with it.
