subdomain vs. subdirectory in web programming

问题:

There are two main strategies for handling multiple "applications" on the web:

• subdomains (e.g. wiki.example.org, blog.example.org, admin.example.org, api.example.org/v1)
• subdirs (e.g. example.org/wiki, example.org/blog, example.org/admin, example.org/api/v1)

What are the differences (advantages and disadvantages) of these two solution when dealing with web programming (e.g. in terms of code organization, browsers security models, javascript etc).

Edit: CW as there's a correct answer, but it's very broad.

回答1:

Besides the fact that from a security standpoint it is a bit easier to isolate an app within a subdomain, I will just comment on what I think is the biggest difference between the two.

Pro's for subdomains:

• You can isolate configuration (for for example apache) per-domain.
• It will be easier to migrate parts of your application to other machines. Sub-directories won't really give you this flexibility.
• Instead of having to use a $baseUri variable in every html template, you can just assume the root of the app is always /.

Cons:

• It will be much more annoying to quickly setup staging or temporary development environments. For every 'app' you will now need DNS of hosts-file entries and webserver configuration. With subdirectories you could drop the app in a directory, and go!
• If you do ever have the requirement to deploy your application on a different system where using / is because of some odd policy not possible, some rewriting might be in order.

My advice:

Make sure you can always do both, which will give you the best of both worlds. Every part of your app should have a configurable base uri that is always respected. As long as you make sure you can always go both ways, then who cares what you do? it's just a url and it can always be changed.

回答2:

• In terms of code organization: The differences are nil, as you can map subdomains to any directory.
• In terms of browser security: JavaScript access across subdomains is possible but has obstacles (see document.domain and consorts). I do not know of anything on the JavaScript side that is completely impossible when working with different sub-domains.

Opinion:

I personally tend towards directories and against subdomains for public addresses. The general public have become used to web addresses beginning with "www." and it creates unnecessary confusion to break this pattern. You will notice that very often people, when given a subdomain to type into the address bar, will automatically start typing in "www." and they will be surprised to learn that an address can be without.

To me, the only good way to use subdomains is for internal purposes to facilitate, or prepare for, the use of different servers (e.g. static.example.com, images.example.com etc.)

回答3:

Personally, I prefer using a subdomain for each application, and then the sub-dirs (whether they are actually sub-directories or not -- preferably they are just re-routed to /index.php by a .htaccess) to denote different states of that application. For example:

admin.blah.com/users/1234/bob,
admin.blah.com/pages/4321/title,
blog.blah.com/archives/2007/5678/title, etc.

The subdomain tells you where you are, and the sub-directories tell you what you're doing.

回答4:

• You can easily 'do' virtual servers on subdomains.
• You can separate out subdomains to different cookies.

You'd be best off recognizing that subdomains are a "major" separation in Web space, and subdirectories a "minor" one. Subdomains are for, well, different domains; you could have different people running different applications on different subdomains. Subdirectories are partitions of a single (sub)domain, separating perhaps different applications by the same user.

Web standards are intentionally very open, but the more you abuse them to create strange hierarchies, the more that will bite you in the end.

回答5:

One of the major advantages of sub-domains is the files they point to can be contained anywhere -- even on another server. My most common usage of a sub-domain is on going development of a live project. For example, you could create the sub-domain:

dev.example.com

and make a copy of your live site, including the entire directory structure. Drop in an .htaccess file to refuse connections from anyone but you and your client's IP, and use this to make changes until the updates are ready to be pushed live.

回答6:

This is a pretty big topic, but here’s some thoughts on sub-domains...

Pros

• Can use a ‘clean’ routing setup if you’re using MVC.

• Very clear division between parts of the system and no danger of namespace overlap.

Cons

• On the downside, there's likely to be more duplication of code on the backend, unless you're clever with library/includes directories and use a shared area.

From an SEO perspective, there's not a great deal of difference these days and indeed tools such as Google Analytics can be instructed to use a specific logging domain.

回答7:

Somewhat related, but not a full answer: subdomains can increase performance when used for css/images/js.

Personally, I like Carson's approach.

回答8:

There have been excellent answers already, so you could check out these links anytime.

• Subdomains and subdirectories

• Sub Domain Vs Sub Directory

回答9:

I think the three most important reasons for using sub.domains, as opposed to sub/directories, are security, security and security. Sub/directories expose the server session to hackers.

For example, if I have two web apps that I put into directories then they will typically share the same session (unless specific steps are taken to prevent/maintain it). So if I have:

domain.com/application1

domain.com/application2

If application2 gets hacked then the hacker can see all the session variables that were set in application1. At this point your session security is reduced to the level of the weakest subapp, i.e., the weakest link in the chain.