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