Talk:Clean URL/Archive 1

Archive 1

RESTful?

Clean URLs, RESTful URLs or user-friendly URLs ... Why RESTful? Thanks, --Abdull (talk) 11:26, 23 August 2011 (UTC)

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://wiki.riteme.site/w/index.php?title=Clean_URL for http://wiki.riteme.site/wiki/Clean_URL, and http://wiki.riteme.site/w/index.php?title=Special:Search&search=clean+url for http://wiki.riteme.site/wiki/Special:Search/clean+url? Even /wiki/Uniform_Resource_Locator?action=edit is an improvement over the messy URL. 68.173.113.106 (talk) 02:08, 25 April 2012 (UTC)

Merge or not?

Need to vote or only to work!? — Preceding unsigned comment added by 189.62.91.148 (talk) 22:15, 20 November 2013 (UTC)

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.

As written (2 May 2014) the article appears to be a "shameless" advertisement. — Preceding unsigned comment added by 50.203.156.9 (talk) 18:59, 2 May 2014 (UTC)

Merge Proposal

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 98.247.53.229 (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. 98.247.53.229 (talk) 02:46, 29 April 2012 (UTC)

I've reversed the direction of the merge proposal. 98.247.53.229 (talk) 02:47, 29 April 2012 (UTC)

Well spotted. That sounds better. I'm surprised there isn't an article on URL rewriting, as that seems to be the topic, but it's a redirect, and it'll end up pointing here, which is probably fine. --Nigelj (talk) 10:50, 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). 50.53.15.51 (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. 50.53.15.59 (talk) 14:06, 2 March 2013 (UTC)

Well I agree with merging clean and semantic URL. Rewriting is a method to change URLs and should be separate from any URL style or design methodologies. 134.134.139.72 (talk) 18:25, 26 March 2013 (UTC)

RESTful doesn't mean Clean, but Clean helps to be RESTful. — Preceding unsigned comment added by 91.180.69.15 (talk) 07:11, 16 August 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)

There's been no sign of consensus to merge this with Rewrite engine since my last comment, so I'm removing the merge tag.  — Scott • talk 12:07, 2 October 2015 (UTC)

Support for semantic URLs in PHP — PATH_INFO

There is support directly in PHP for semantic URLs. Consider an URL like:

http://www.example.com/wiki/index.php/SomePage?action=edit

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

This is, I suppose, an only partially semantic URL. Here is a reference: http://php.net/reserved.variables.server.php CibléEnAmérique (talk) 19:15, 12 September 2014 (UTC)

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)

The path info concept originates with CGI (basically ancillary path components past the specification of the script) and is hardly specific to PHP. It might be a notable topic to write about within this article but would be careful of the possibly of slanting things too much in the PHP only direction. Perhaps you should consider URL mapping more generally. 50.126.125.240 (talk) 23:24, 28 November 2015 (UTC)

Archive 1