|WikiProject Websites / Computing||(Rated Start-class, High-importance)|
|WikiProject Internet||(Rated Start-class, Mid-importance)|
|Text from this version of Clean URL was copied or moved into Semantic URL with this edit on 6 June 2014. The former page's history now serves to provide attribution for that content in the latter page, and it must not be deleted so long as the latter page exists. The former page's talk page can be accessed at Talk:Clean URL.|
I'm not sure where the unusual capitalization comes from. "RESTful" is more-or-less defined in the representational state transfer (REST) article (which uses the same capitalization). --DavidCary (talk) 05:40, 18 July 2012 (UTC)
Examples from Wikipedia?
Shouldn't we use examples from Wikipedia, such as http://en.wikipedia.org/w/index.php?title=Clean_URL for http://en.wikipedia.org/wiki/Clean_URL, and http://en.wikipedia.org/w/index.php?title=Special:Search&search=clean+url for http://en.wikipedia.org/wiki/Special:Search/clean+url? Even /wiki/Uniform_Resource_Locator?action=edit is an improvement over the messy URL. 22.214.171.124 (talk) 02:08, 25 April 2012 (UTC)
This page is basically a duplication of Rewrite engine. There is very little that the two don't share. In fact, Pretty URL already points to that page. It makes sense to merge these pages 126.96.36.199 (talk) 18:15, 27 April 2012 (UTC)
- There are many ways to achieve clean URLs other than using a rewrite engine. Also, there is more to designing clean and long-lived URLs than simply deciding to use a rewrite engine. If the articles are that similar, it is probably because whoever wrote Rewrite engine got bogged down in why you might want to use one, rather than what they are, where they came from, how widespread they are, what the alternatives are, where they are headed in the future, etc. i.e. things that would all suit an encyclopedia article of that name. Along with a link to this article to help clarify what their main purpose is, of course. They are not equivalent topics, and their should be little duplication. --Nigelj (talk) 20:58, 27 April 2012 (UTC)
- Pretty URL is much closer to Clean URL, and so I have altered that redirect to point here. Thanks for pointing that out. --Nigelj (talk) 21:01, 27 April 2012 (UTC)
- You might be right. Perhaps the merge proposal goes the wrong way. As things sit right now, the Rewrite engine article has this to say about rewrite engines: "A rewrite engine is software located in a Web application framework running on a Web server that modifies a web URL's appearance. This modification is called URL rewriting." The rest of the article is about Clean/Pretty URLs: what they are and their advantages/disadvantages. It would almost seem like "Rewrite engine" should be a subtopic to this page. 188.8.131.52 (talk) 02:46, 29 April 2012 (UTC)
- I've reversed the direction of the merge proposal. 184.108.40.206 (talk) 02:47, 29 April 2012 (UTC)
- I agree that if they are merged, they should be merged to the more general name -- clean URL, rather than the more specific name rewrite engine (which is only one of several ways to produce websites that have clean URLs). p.s.: I've also reverted Friendly URL to its original redirect to clean URL; for a while it was a redirect to rewrite engine. --DavidCary (talk) 05:40, 18 July 2012 (UTC)
I added a proposal to merge from Clean URL to Semantic URL. These seem to basically be the same idea and "semantic" seems the more general term (though not sure which is really more notable). 220.127.116.11 (talk) 22:15, 3 August 2012 (UTC)
Definitely no. Clean URLs is just one of several functions that a Rewrite Engine performs and a Rewrite Engine is just one way to process Clean URLs. So there should be some overlap and cross referencing. If the two entries are too similar it is more an indication that the entries need elaboration, not that they should be merged. The documentation for MOD_REWRITE provides many examples of using a rewrite engine for functions that are not Clean URLs. See: ″Ralf Engelschall's Rewriting Guide -- Numerous examples from the man who invented mod_rewrite.″ http://httpd.apache.org/docs/2.0/misc/rewriteguide.html TPiwowar 16:12, 19 January 2013 (UTC) — Preceding unsigned comment added by Tpiwowar (talk • contribs)
- Well I shall have to totally disagree as a rewrite engine is only one way to obtain "clean URLs". Another and probably far better one is to just design your web API to use such to begin with (without any rewriting). Certainly clean or semantic URLs can be attained through rewriting of course but I do not see a clear difference/delineation between the two terms/nomenclature--thus the merge proposal. 18.104.22.168 (talk) 14:06, 2 March 2013 (UTC)
- I've Done the merge of Clean URL into Semantic URL. The merge proposal for rewrite engine stands; I think it's a topic that could merit a proper article of its own. — Scott • talk 10:50, 6 June 2014 (UTC)
- oppose merge of Rewrite engine. URLs are goals, rewrite engines are one technique with which to achieve them.
- I support the merge of clean URL and semantic URL. These are the same entity, defining it at the same level. The engines though are different: they're the means of achieving the URL. Also rewrite engines are just one way of doing this. Viam Ferream (talk) 09:51, 15 September 2014 (UTC)
Merge or not?
Article refs make this term unique to cited vendors (Wordpress
The term "slug" is not ubiquitous term. This spec: https://tools.ietf.org/html/rfc5023#page-30 uses the term but its meaning is very different. It doesn't appear in a WWW Consortium spec. The concept of "clean" is subjective and not a bad one to use when referring to a URL that does not contain a query string. The term has no place in technical documentation because it's already defined and has an entirely different meaning.
A URL may or may not contain variables. Variables and their value are what make up a Query String. To the extent they help determine where a resource appears in search engine results has nothing to do with whether or not they're easy to read by a human. That is, a URL that's easy to read may get a better placement from a search engine that's less complex than, (as an example) Yahoo's search engine but it's the search engine that determines placement.
If there's a search engine that gives a better rating to a resource, solely because it's human readable, that engine should be cited as a reference.
Support for semantic URLs in PHP — PATH_INFO
There is support directly in PHP for semantic URLs. Consider an URL like:
All parts of this URL are (or can be made) semantic except for the name of the script itself, and can be accessed through PHP:
<?php header('Content-type: text/plain'); echo 'REQUEST_URI: ', $_SERVER['REQUEST_URI'], "\n"; echo 'SCRIPT_NAME: ', $_SERVER['SCRIPT_NAME'], "\n"; echo 'PATH_INFO: ', $_SERVER['PATH_INFO'], "\n"; echo 'QUERY_STRING: ', $_SERVER['QUERY_STRING'], "\n";
which in this case will output
REQUEST_URI: /wiki/index.php/SomePage?action=edit SCRIPT_NAME: /wiki/index.php PATH_INFO: /SomePage QUERY_STRING: action=edit
- Whilst this is the sort of system function that would be useful to a PHP developer building a site with semantic URLs, I'm failing to see what makes this low-level HTTP-bound function in any way "semantic"? Isn't this the layer that isn't semantic and that the developer would then have to start building upon? Viam Ferream (talk) 09:47, 15 September 2014 (UTC)
- I guess my point is that PATH_INFO in PHP can be a major component of a semantic URL, and that web-server-based "URL rewriting" isn't absolutely necessary to develop URLs that are clear and meaningful. In a sense, you could say that "semantic" URLs are meaningful to humans, and how they are interpreted by a computer is irrelevant, but some simplicity in how they are implemented (as opposed to overly complex and web-server-dependent rewriting rules that in turn have to be taken into account by the application) is necessary to make these URLs robust and useful. CibléEnAmérique (talk) 22:30, 16 September 2014 (UTC)