| paulb@357 | 1 | <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> |
| paulb@436 | 2 | <html xmlns="http://www.w3.org/1999/xhtml"><head> |
| paulb@436 | 3 | |
| paulb@436 | 4 | <title>URLs and Paths</title><meta name="generator" content="amaya 8.1a, see http://www.w3.org/Amaya/" /> |
| paulb@436 | 5 | <link href="styles.css" rel="stylesheet" type="text/css" /></head> |
| paulb@436 | 6 | |
| paulb@327 | 7 | <body> |
| paulb@327 | 8 | <h1>URLs and Paths</h1> |
| paulb@357 | 9 | <p>The URL at which your application shall appear is arguably the first |
| paulb@357 | 10 | part |
| paulb@357 | 11 | of the application's user interface that any user will see. Remember |
| paulb@357 | 12 | that a user of your application does not have to be a real person; in |
| paulb@357 | 13 | fact, |
| paulb@327 | 14 | a user can be any of the following things:</p> |
| paulb@327 | 15 | <ul> |
| paulb@327 | 16 | <li>A real person entering the URL into a browser's address bar.</li> |
| paulb@327 | 17 | <li>A real person linking to your application by writing the URL in a |
| paulb@357 | 18 | separate Web page.</li> |
| paulb@357 | 19 | <li>A program which has the URL defined within it and which may |
| paulb@357 | 20 | manipulate the URL to perform certain kinds of operations.</li> |
| paulb@327 | 21 | </ul> |
| paulb@357 | 22 | <p>Some application developers have a fairly rigid view of what kind of |
| paulb@357 | 23 | information a URL should contain and how it should be structured. In |
| paulb@357 | 24 | this guide, we shall look at a number of different approaches.</p> |
| paulb@327 | 25 | <h2>Interpreting Path Information</h2> |
| paulb@357 | 26 | <p>What the URL is supposed to do is to say where (on the Internet or |
| paulb@357 | 27 | on an |
| paulb@357 | 28 | intranet) your application resides and which resource or service is |
| paulb@357 | 29 | being |
| paulb@327 | 30 | accessed, and these look like this:</p> |
| paulb@327 | 31 | <pre>http://www.boddie.org.uk/python/WebStack.html</pre> |
| paulb@357 | 32 | <p>In an application the full URL, containing the address of the |
| paulb@357 | 33 | machine on which it is running, is not always interesting. In the |
| paulb@357 | 34 | WebStack API (and in other Web programming frameworks), we also talk |
| paulb@357 | 35 | about "paths" - a path is just the part of the |
| paulb@357 | 36 | URL which refers to the resource or service, ignoring the actual |
| paulb@357 | 37 | Internet |
| paulb@357 | 38 | address, and so the above example would have a path which looks like |
| paulb@357 | 39 | this:</p> |
| paulb@327 | 40 | <pre>/python/WebStack.html</pre> |
| paulb@327 | 41 | <p>When writing a Web application, most of the time you just need to |
| paulb@357 | 42 | concentrate on the path because the address doesn't usually tell you |
| paulb@357 | 43 | anything |
| paulb@327 | 44 | you don't already know. What you need to do is to interpret the path |
| paulb@357 | 45 | specified in the request in order to work out which resource or service |
| paulb@357 | 46 | the user is trying to access.</p> |
| paulb@327 | 47 | <div class="WebStack"> |
| paulb@327 | 48 | <h3>WebStack API - Path Methods in Transaction Objects</h3> |
| paulb@357 | 49 | <p>WebStack provides the following transaction methods for inspecting |
| paulb@357 | 50 | path |
| paulb@327 | 51 | information:</p> |
| paulb@327 | 52 | <dl> |
| paulb@327 | 53 | <dt><code>get_path</code></dt> |
| paulb@357 | 54 | <dd>This gets the entire path of a resource including parameter |
| paulb@357 | 55 | information (as described in <a href="parameters.html">"Request |
| paulb@436 | 56 | Parameters and Uploads"</a>).<br /> |
| paulb@436 | 57 | An optional encoding parameter may be used to assist the process of converting the path to a Unicode object - see <a href="encodings.html">"Character Encodings"</a> for more information.</dd> |
| paulb@327 | 58 | <dt><code>get_path_without_query</code></dt> |
| paulb@357 | 59 | <dd>This gets the entire path of a resource but without any parameter |
| paulb@357 | 60 | information.</dd> |
| paulb@327 | 61 | </dl> |
| paulb@327 | 62 | </div> |
| paulb@357 | 63 | <h2>Query Strings</h2> |
| paulb@335 | 64 | <p>Sometimes, a "query string" will be provided as part of a URL; for |
| paulb@335 | 65 | example:</p> |
| paulb@335 | 66 | <pre>http://www.boddie.org.uk/application?param1=value1</pre> |
| paulb@357 | 67 | <p>The question mark character marks the beginning of the query string |
| paulb@357 | 68 | which |
| paulb@357 | 69 | contains encoded parameter information; such information and its |
| paulb@357 | 70 | inspection |
| paulb@335 | 71 | is discussed in <a href="parameters.html">"Request Parameters and |
| paulb@335 | 72 | Uploads"</a>.</p> |
| paulb@357 | 73 | <h2>More About Paths</h2> |
| paulb@357 | 74 | <ul> |
| paulb@357 | 75 | <li><a href="path-info.html">Paths To and Within Applications</a></li> |
| paulb@357 | 76 | <li><a href="path-design.html">Path Design and Interpretation</a></li> |
| paulb@357 | 77 | <li><a href="path-info-support.html">Path Info Support in Server |
| paulb@357 | 78 | Environments</a></li> |
| paulb@357 | 79 | </ul> |
| paulb@436 | 80 | </body></html> |
