> Only downside is that the urls look a bit ugly.

If /fred returns HTML, then the URL is perfectly fine, since the only real consumer of fred.md or fred.json are automated systems/API clients, and they couldn't care less what the URL looks like, only that it's predictable.

It is a good trick with GitHub though that you can add .patch or .diff to the url to fetch the content without styling

Another good one for GitHub is that you can do

    github.com/[username].png

to get that username's profile picture.

And

        github.com/[username].keys

to get their ssh keys

We have

  github.com/[username].gpg

to get their OpenPGP keys, too!

Just go for .secrets to get it all in one request.

2 things.

What about any of that is "secret?"

This endpoint does not work.

Try .credit-card instead. Pretty sure that one works.

It's not just styling. The content is actually a `git format-patch` patch for the former a unified-format diff for the latter.

Adding .pibb to a gist url is another nice trick

But doesn't << /fred.md >> beat the heck out of something like << /fred?format=md >>?

Depends. Including it in the location part of the URL could make it harder to understand if you have multiple parameters, instead of just one. Using query parameters makes it very explicit, which can be good or bad depending on your use case, while sticking it into the URL makes it implicit.

Together with that, you can also go for putting it in the `hash` part of the URL, if you want to keep it a secret from the server, as the server doesn't receive those parts, `/fred/#format=md`. In this case, it doesn't make much sense, but useful to know for other things, like keys and whatnot.

Is don’t think I that hash method would work since that part of the URL isn’t sent to the server. It’s strictly used by the client to decide which part of the response we to show.

Server has no need for it.

I think if this is the URL behind any sort of "api" prefix in the URL (subdomain, or subdirectory) I don't see why not? It's always worked out pretty darned fantastic.

Reddit does this too. You can add a ".json" suffix to any post and get the JSON response.

also ".rss" to get a RSS feed

I use that with a custom feed; works well.

The URLs are different, suffix instead of the typical prefix, that's not really content negotiation.

It also works quite well with the browser save feature. Curl and wget will also save to a nice name by default. It may be nice if content-type tracking was universal but unfortunately file-extensions are probably the most robust way of tagging some data with a type (other than magic bytes). You can save that JSON, email it, archive it, upload it to a fileserver, someone downloads it again, decompresses it and uploads it in an HTTP form and the result will probably still be identified as JSON and highlighted by default in your editor.

You can also easily serve *.html, *.json, and *.md as static files.

Who cares if urls are ugly?

Front-End Developers

Also that's why single page applications are no longer technically single page.

    https://example.com/#!/
    https://example.com/#!/about/
    https://example.com/#!/users/

Are all the same page as far as the browser concerns, and if you move from `/#!/` to `/#!/users/`, and reload the page, you still load the same page (i.e. `/`).

But that was too ugly for URLs, so modern websites now use browser history APIs just so they can remove 3 characters from the URL and do stuff like:

    https://example.com/
    https://example.com/about/
    https://example.com/users/

Sure, if you load `/` and move to `/about/` you don't load a new page because of browser history APIs; but if you then refresh, now you load a different, uncached page (`/about/`, instead of `/`) even if the HTML in the response is exactly the same as in `/`.

Sure, the difference is not much, but to me it still seems like a waste when the response could have been cached already like in the first example.

> But that was too ugly for URLs, so modern websites now use browser history APIs just so they can remove 3 characters from the URL and do stuff like

Would back/forward buttons continue to work if we decided not use browser history APIs?

The other poster is wrong, the entire reason the history API exists is specifically because when these SPA frameworks first came onto the scene one of the things that was broken was history.

So they invented the history API's so SPA's could stop breaking some of the user expectations they were breaking.

Yes, and a quick test with Mithril.js confirms it.

I could try with something like React, but that's too much for a quick test.

Mithril.js also probably uses the history API?

.replaceState() will replace current url without putting it in the history, so back won't work, while .pushState() does.

The real reason for moving (back) from fragment URLs to real URLs is because the latter can serve different content on the initial load - specifically, they can act as actual webpages that use javascipt for progressive enhancement but work immediately whereas your / needs to display a spinner while you send of additional network requests to retrieve the content and build the page.

The first one always requests / from the server when landed on/refreshed. The other one does not. This fact can be acted upon.

That issue can be solved with service workers.

What does the ! symbol do in url fragments?

It was part of a scheme to make SPAs indexable by search engines. Google deprecated it back in 2015, as Googlebot can now execute JS.

https://developers.google.com/search/blog/2009/10/proposal-f...

Marketing

These are the same people who make every link in the emails they send 1kB of tracking parameters?

Those navigating with a keyboard.

Shopify does that.

Well, at least the appending .json to everything.

Shopify is written in Rails, no? That's how Rails does it.