do we need separate hosts/uris for the api and the server?

[npdoty]

(Please forgive my relative ignorance on the design practices.)

Do we need separate URIs for the API and for the Web-accessible server? It appears as if api.py is returning results compatible with the ActivityPub spec and that views.py and related return results for consumption by a Web browser. Rather than maintaining separate URI structures (whether on two different hosts or not), could the code just switch between these two based on the headers? If a user agent only Accepts application/ld+json, then we return ActivityPub JSON; if the user agent is expecting text/html, then it's a web browser and we should render a nice template.

[rowanlupton]

This is how Mastodon handles it! The reason why I've got separate URIs is bc my focus here is to have an API that anybody can write a frontend to interface with, as long as they use the AP C2S protocol, and if i was going to do it just based on headers i'm not sure if i could separate out the client and API code.

[npdoty]

Whoa, I'm learning that about Mastodon now too (looking at Mastodon.py) and I'm honestly really surprised. Maybe because I'm a REST kind of person, but it seems to me like you'd want the same URL to represent the same resource, even if the user agent is using content negotiation and wants to view it in a particular way. Otherwise you have to design two different URL schemes and always remember to keep them both up to date and refer to the right one in the right places.

I guess this is a common question, as I see lots of StackOverflow questions about it and there are a few Flask extensions that deal with it. flask-accept is a small, relevant one. But I imagine that design does make it harder if you want to keep the HTML-generating and ActivityPub/JSON-generating code entirely separate.