So this is right at the limits of my understanding - I’m not a web admin, and I’m not a DNS dev; I’m a webapp backend dev. I’m coming at this from the perspective of best-practices for API and service design.
I’m generally talking about webpages that are services, both because that’s what I work on, and because that’s when trust actually matters to me. In these cases, a lot of page content is dynamic and cannot be hosted by a CDN.
For domains that are hosting services, it makes sense to have a subdomain for each service or class or service, but the only client that makes the URL visible is the browser so I want my landing page to not require typing in a subdomain, to reduce friction.
Subdomains are then defined by their purpose to the user, not by the type of resource they’re hosting. The typo of resource is determined by the accept header. If a client wants to access a resource using HTML or by xml or by json or by txt, they specify that in the header, and the webserver returns the resource in the requested representation.
Using a subdomain for a specific representation rather than for a specific utility seems lazy, which sets off red flags, if I’m required to enter it.
Edit, just in case it’s useful to explain what I mean by subdomain “purpose”.
To use a fictional version of Google where they didn’t have separate branding for all their services.
Search: search.google.com
Video: video.google.com
Music: music.video.com
Gmail: mail.google.com
Productivity suite: office.google.com
Etc.
These are what I feel subdomains are best used for. Clients can use headers to control how the resources for each of those services get represented. You don’t have representation-specific subdomains. If you only offer one service, then you don’t need subdomains; you can still have them but don’t force your users to use it, and probably still best to name it after the purpose, in case the company expands into other product domains.
It’s like the difference between “package by feature” and “package by layer”. Having a representation-specific subdomain is packaging by layer.
So this is right at the limits of my understanding - I’m not a web admin, and I’m not a DNS dev; I’m a webapp backend dev. I’m coming at this from the perspective of best-practices for API and service design.
I’m generally talking about webpages that are services, both because that’s what I work on, and because that’s when trust actually matters to me. In these cases, a lot of page content is dynamic and cannot be hosted by a CDN.
For domains that are hosting services, it makes sense to have a subdomain for each service or class or service, but the only client that makes the URL visible is the browser so I want my landing page to not require typing in a subdomain, to reduce friction.
Subdomains are then defined by their purpose to the user, not by the type of resource they’re hosting. The typo of resource is determined by the
acceptheader. If a client wants to access a resource using HTML or by xml or by json or by txt, they specify that in the header, and the webserver returns the resource in the requested representation.Using a subdomain for a specific representation rather than for a specific utility seems lazy, which sets off red flags, if I’m required to enter it.
Edit, just in case it’s useful to explain what I mean by subdomain “purpose”.
To use a fictional version of Google where they didn’t have separate branding for all their services.
Search: search.google.com
Video: video.google.com
Music: music.video.com
Gmail: mail.google.com
Productivity suite: office.google.com
Etc.
These are what I feel subdomains are best used for. Clients can use headers to control how the resources for each of those services get represented. You don’t have representation-specific subdomains. If you only offer one service, then you don’t need subdomains; you can still have them but don’t force your users to use it, and probably still best to name it after the purpose, in case the company expands into other product domains.
It’s like the difference between “package by feature” and “package by layer”. Having a representation-specific subdomain is packaging by layer.