Take time to design the structure of the URL address do not resign

The design of the URL is a very complex problem, I can't say there is a "right" solution-it is similar to other aspects of the design, there are good URL design, there are bad URL design, in the case between the two different-it is subjective. This does not mean, however, that there is no best practice for creating very good URLs. I hope that some of the URL design best practices I've learned over the years can impress you, and I'll explain why I think it's exciting to work with the new HTML5 JavaScript history API.

is to spend some time designing the structure of your URL address. Don't leave it to your framework to decide, not to resign, to rely on luck. Think carefully and find out a kind of experience carefully.

The design of the URL is a very complex problem, I can't say there is a "right" solution-it is similar to other aspects of the design, there are good URL design, there are bad URL design, in the case between the two different-it is subjective.

This does not mean, however, that there is no best practice for creating very good URLs. I hope that some of the URL design best practices I've learned over the years can impress you, and I'll explain why I think it's exciting to work with the new HTML5 JavaScript history API.

Why do you need to design your URL

The URL bar has become a major attraction for modern browsers, and it's not just a URL bar-you can type in a partial URL, and then the browser will call out the exact full address you're looking for with black magic. When I entered the resque issues in my URL bar, the first result was https://github.com/defunkt/resque/issues.

URLs are globally unified and can be used in chrome, Safari, Internet Explorer, CURL, wget, your iphone, Android, or even on a sticky note. They are a global common syntax for web networks. But don't take it for granted.

Any semi-technical user who regularly accesses your site should be able to browse the 90% parts of your application based on the URL structure in memory. To be able to do this, your URLs need to be practical, almost as if they were mathematical equations--many simple rules are combined into a strategic way to get the pages they want.

The top part is the most important

The most valuable aspect of a URL is the portion of its top level. It seems to me that after the idea is formed, this is the first thing that any startup should have to discuss, far away from any technical discussion before any code is written. This top-level section will change the basis of your site's functionality.

Am I exaggerating? It might look like this--but there will be 1,000,000 of users in the future, and think about how much it will impact. Think about how important it is for Facebook to launch a username. The available URLs are like real estate, and the top part is the best asset that is reflected outside.

Another quick tip--whenever you build a new site, consider the list of blacklisted URLs (perhaps a bit of a bad URL design from the Quora URL).

Namespaces are a great tool for extending URLs

Namespaces can be a great way to build a useful URL structure that is easily remembered in subsequent use. What is the namespace I'm talking about here? I mean, the part where the different content is indicated in the URL. An example:

Https://github.com/defunkt/resque/issues

In the URL above, Defunkt/resque is the namespace. Why is this useful? This is because any part after this URL suddenly becomes a new top-level section, so you can go to any one of the "user"/"repo" and then add/issues or possibly/wiki to get the same page, but under different namespaces.

To keep the namespace clear, don't start by putting some content under the/feature/"user"/"repo", or under the "user"/"repo"/feature. For namespaces, it must be uniform to be effective.

Query string is a great way to filter and sort

About the query string Web has a chaotic past, I have seen a variety of things, from each page using the same URL with different query parameters of the site, to a query string parameters are not used by the site, all kinds of situations.

I like to think of the query string as the knob of the URL--it adjusts your current view and tunes it to your liking, which is why they are so good at sorting and filtering these behaviors. By sticking to a unified model (such as SORT=ALPHA&DIR=DESC), you'll make sorting and filtering through the URL bar easy to remember.

There is one last thing about the query string: In the absence of additional query strings, the page should be valid, it may give a different page, but no query string URL should be rendered out of the page.

Non-ASCII URLs for English sites are bad

The world is a complex place, full of ¿ümlåts?,¡êñyés! and various daunting character ☄. These characters will not have a place in the URL of any English website. Using the English keyboard to enter these characters is very complex, and many times it is extended to some confusing characters in the browser (have you seen xn--n3h in the URL?). This is a ☃.

URLs are designed for people--not for search engines

I grew up in this industry and learned how to play the game of search engines (well, Google) to make money from my affiliate marketing. So the keyword stack URL approach to me is not unfamiliar. It's quite common to end a URL as follows:

Http://guitars.example.com/best-guitars/cheap-guitars/popular-guitar

For SEO purposes, the use of this URL will be good, fortunately, 2003 Google's hurricane-type update eliminates any ranking advantage of such URLs. Unfortunately, the professional SEO industry is surrounded by plunder, so it may also suggest that you use as many keywords as you possibly want to stack your URLs.

Remember the other points:

1. Underline only one bad word, adhere to the use of dashes.

2. Use short, complete and known words. If there is a dash or a special character in a section, the word may be too long.

URLs are provided for people and are designed for people who use them.

A URL is a protocol

A URL is a protocol that supplies something as long as possible in a predictable location. Once your first visitor clicks on the URL, you implicitly enter the agreement that if they remember to come to the page or click the Refresh button, they will see the same thing.

Do not change your URL after it has been released to the public, and if you absolutely need to change your URL, plus redirect-this will not cause alarm.

Everything should have a URL

In an ideal environment, any individual on-screen display on your site should have a URL that can be copied and pasted to produce the same screen content again on another tab or browser. To be fair, this is not entirely possible. Unless you are recently using a new HTML5 browser's history Javascript API. It is noteworthy that there are two new methods:

Onreplacestate-This method replaces the current URL in browser history and makes the back button unaffected.

onpushstate– This method pushes a new URL into the browser's history instead of the URL in the URL bar and adds it to the browser's history stack (which affects the back button).

When to use Onreplacestate and when to use Onpushstate

These new methods allow us to change the entire path in the URL bar, not just the anchor element. With this new and powerful feature comes a design responsibility-we need to find out the experience of using back buttons.

To determine which method to use, ask yourself such a question: does this behavior produce new content? Or is it a different display of the same content?

1. Create new content-you should use onpushstate (e.g. pagination link)

2. Different display of the same content-you should use Onreplacestate (for example: sorting and filtering)

Use your own judgment, but these two rules should match your 80%. Consider what you want to see when you click the Back button and do what you want.

Link behavior should be like a link

Link elements such as "a" and "button" have many good built-in features. If you click them or command them, they will open a new window. When you hover over it, your browser will tell you its URL address in the status bar. Do not spoil this behavior when using Onreplacestate and onpushstate.

1. Embed the position of the AJAX request in the HREF attribute of the anchor element.

2. Returns the true value from the JavaScript click handler when the key clicks or commands click on them.

This is a fairly simple approach to using a quick conditional judgment within your click handler. Here is a jquery-compatible example fragment:

$ (' A.ajaxylink '). Click (function (e) {

API Browser does not support backing of the history API

if (! Replacestate ' in Window.history) "return True

Ensure the normal click behavior of the key, control, and command

if (E.which = 2 | | e.metakey | | e.ctrlkey) {

return True

}

Do some great things and then change the URL

Window.history.replaceState (null, "New Title", '/some/cool/url ')

return False

})

URL specific to post behavior needs to be revoked

In the past, the development community loved to create URLs that could not be reused, and I like to refer to them as POST-specific (post-specific) URL which are URLs that appear in your address bar after you submit a form. But when you try to copy and paste these URLs into a new tab, you get the wrong address.

There is no excuse for this type of Ur, which is specific to post behavior URLs for redirection and APIs-not for end users.

A great example

1. The user-generated URL section uses only ASCII characters (Defunkt, Resque).

2. "Pull" is a short version of "Pull Request"-a single word that can easily be associated with a source word.

3. The scope of the pull request (pull request) is limited to Defunkt/resque (starting from 1).

4. The anchor points to a scrolling position and the contents are not blocked.

Knowledge Points: There are many different formats for URLs-Find out patch and diff versions.

The beginning of an era

I hope that as the use of the new JavaScript API increases, designers and developers will spend some time designing URLs. This is an important part of the usability of any Web site, but I see too many URLs that ignore it. Although it is easy to redesign the look and feel of a Web site, it is much harder to redesign the URL's structure.

But I was also very excited, and over the years I have observed changes in the URL. Sometimes a hard link is sacrificed at the altar of Ajax, sometimes sacrificing performance to generate a real URL for the user. Eventually we'll come to a point where we can get the performance and usability benefits of some of the page's rendering, while gaining experience in designing structured and refined URLs.

Are there any questions or suggestions for the content of this post? Email me, please be polite and reasonable, I will respond, perhaps even posted to this site.