Nutzung reservierter Zeichen in URLs/URIs

[sHo]

Hallo werte Kollegen und Experten der Web-Entwicklung!

Im groben suche ich nach möglichen Problemen bzw. Szenarien, welche unvermeidbar auftreten können wenn man reservierte Zeichen in URLs bzw. URIs verwendet.

Wer sich vorab informieren möchte hier der Link auf Wikipedia :
Wikipedia : URL
Wikipedia : URI
Wikipedia : URL Encoding
(Die englischen Artikel sind auch zu empfehlen.)

Zu den reservierten Zeichen zählen :
 ! # $ % & ' ( ) * + , / : ; = ? @ [ ]

Wie ich beim W3C schon in Erfahrung bringen konnte sind diese Zeichen nicht explizit reserviert oder die Nutzung gar verboten. Da aber die Zeichen in einigen Fällen jedoch ihre eigne Bedeutung haben sollte man laut W3C mit Ihrer Nutzung sehr achtsam sein.

Im speziellen möchte ich nur diese Zeichen verwenden :
 , : ( )

Weiterhin würde sich die Nutzung nur auf den Pfad in der URL/URI beschränken. Eine Fehlinterpretation des Doppelpunktes (normal als Trennzeichen zwischen Server/Domain und Port genutzt) sehe ich damit als ausgeschlossen. Was das Komma und beide Klammer-Zeichen angeht bin ich mir noch unsicher. In einigen Tests unter aktuellem LAMP gab es aber keinerlei Probleme.

Wer sich unter euch jetzt fragt "Was soll das Ganze denn" oder "Wie was? Hab nix verstanden!" hier mal ein einfaches Beispiel wie das ganze ausschauen könnte :

http://www.example.org/function/radom(min:3,max:4)

Ganz richtig, der Ansatz daran ist über URLs/URIs Funktionen aufzurufen und Parameter zu übergeben. Das wieso und wozu möchte Ich hier aber nicht zum Thema machen. Wie gesagt suche ich nach Problemen und Szenarien die mit der Art URLs/URIs auftreten könnten - nicht nur in Browsern.

Ich bitte euch dem Thema offen gegenüber zu treten und den technischen Aspekt und die jene Probleme in den Vordergrund zu stellen. Das es keine gängige Praxis ist und es andere Techniken gibt ist mir schon bekannt.

Danke für eure Zeit und Interesse!

Gruß
stefan

[Beat]

Wer sich unter euch jetzt fragt "Was soll das Ganze denn" oder "Wie was? Hab nix verstanden!" hier mal ein einfaches Beispiel wie das ganze ausschauen könnte :

http://www.example.org/function/radom(min:3,max:4)

Ganz richtig, der Ansatz daran ist über URLs/URIs Funktionen aufzurufen und Parameter zu übergeben.

Dann verwende Query-Strings dafür.
Ein Pfad verweist auf eine Ressource mit hoffentlich garantiertem Inhalt.
Das ist Bei funktionen und Parametern bei dir nicht gegeben.

Das wieso und wozu möchte Ich hier aber nicht zum Thema machen.

Solltest du aber. Denn es geht nicht nur darum, was deine Anwendung aus dem Pfad machen kann, sondern wie andere Agents diesen Pfad sehen und behandeln.

mfg Beat

[Gunnar Bittersmann]

@@Beat:

Dann verwende Query-Strings dafür.
Ein Pfad verweist auf eine Ressource mit hoffentlich garantiertem Inhalt.
Das ist Bei funktionen und Parametern bei dir nicht gegeben.

Wer sagt das?

Woher willst du wissen, wie der Server den Path "/function/radom(min:3,max:4)" auswertet?

Möglicherweise verweist der URI ja auf eine Resource mit garantiertem Inhalt.

Live long and prosper,
Gunnar

[Beat]

@@Beat:

Dann verwende Query-Strings dafür.
Ein Pfad verweist auf eine Ressource mit hoffentlich garantiertem Inhalt.
Das ist Bei funktionen und Parametern bei dir nicht gegeben.

Wer sagt das?

Woher willst du wissen, wie der Server den Path "/function/radom(min:3,max:4)" auswertet?

Möglicherweise verweist der URI ja auf eine Resource mit garantiertem Inhalt.

Wie verstehst du random(min:3,max:4).
Deutet doch darauf hin: exakte URL zufälliger Inhalt
aber man könnte auch auf die Idee kommen
get(3)
get(3.1)
get(3.14)
get(3.141)

mfg Beat

[Gunnar Bittersmann]

@@Beat:

Wie verstehst du random(min:3,max:4).

Als Parameter, den das Script auswertet, welches sich hinter der Resource http://www.example.org/function/ verbirgt.

Live long and prosper,
Gunnar

[Beat]

@@Beat:

Wie verstehst du random(min:3,max:4).

Als Parameter, den das Script auswertet, welches sich hinter der Resource http://www.example.org/function/ verbirgt.

Ach so als pathinfo.
Die Ressource ist dann aber
http://www.example.org/function
und / gehört bereits zur pathinfo, dzw ist deren delimiter

Ja, aber das ist die rein serverseitige Behandlung und behebt damit den unendlichen Adresseraum, der auf intransparenten Content verweist, nicht.

Google und Co kommen deshalb mit Queries besser zurecht, weil sie sich Freiheiten in der Bewertung einzelner Komponenten nehmen können, und vor allen intern eine einheitliche Sortierung der Komponentenreihenfolge vornehmen können. All dies fällt dahin, wenn man Queries in die Form von Pfaden pressen will.

mfg Beat

[Der Martin]

Hallo,

»» »» Wie verstehst du random(min:3,max:4).
»» Als Parameter, den das Script auswertet, welches sich hinter der Resource http://www.example.org/function/ verbirgt.
Ach so als pathinfo.

zum Beispiel.

Die Ressource ist dann aber
http://www.example.org/function
und / gehört bereits zur pathinfo, dzw ist deren delimiter

Nein, alle Parameter, die das Ergebnis beeinflussen, dienen der Identifizierung der Ressource und sind somit als Teil des URI zu sehen. Dabei ist es völlig egal, wie diese Informationen ausgewertet und verarbeitet werden.

Ja, aber das ist die rein serverseitige Behandlung und behebt damit den unendlichen Adresseraum, der auf intransparenten Content verweist, nicht.

Äh, wie bitte?

Google und Co kommen deshalb mit Queries besser zurecht, weil sie sich Freiheiten in der Bewertung einzelner Komponenten nehmen können, und vor allen intern eine einheitliche Sortierung der Komponentenreihenfolge vornehmen können. All dies fällt dahin, wenn man Queries in die Form von Pfaden pressen will.

Jeder Webprogrammierer hat diese Freiheit, seine URIs so zu definieren, wie es für den Anwendungsfall, für den Anwender oder für die Suchmaschine am günstigsten ist (je nachdem, was ihm am meisten am Herzen liegt). Das ist kein Privileg von "Google & Co".

So long,
 Martin

[sHo]

Bitte entschuldigt - das Beispiel mit random war ach echt ungünstig gewählt. Ich habe es versucht hier besser zu beschreiben.

»» Google und Co kommen deshalb mit Queries besser zurecht, weil sie sich Freiheiten in der Bewertung einzelner Komponenten nehmen können, und vor allen intern eine einheitliche Sortierung der Komponentenreihenfolge vornehmen können. All dies fällt dahin, wenn man Queries in die Form von Pfaden pressen will.

Jeder Webprogrammierer hat diese Freiheit, seine URIs so zu definieren, wie es für den Anwendungsfall, für den Anwender oder für die Suchmaschine am günstigsten ist (je nachdem, was ihm am meisten am Herzen liegt). Das ist kein Privileg von "Google & Co".

Ich kann Martin nur zustimmen, wie ein Programmierer bzw. das 'Programm' den Pfad bzw. das Query dann interpretiert und verarbeitet ist nicht daran gebunden nur Queries zu verwenden.

Danke,
stefan

[sHo]

Ich freue mich über eure Antworten. Vielleicht ist es doch nicht schlecht das wieso und wozu zu erläutern.

Dann verwende Query-Strings dafür.
Ein Pfad verweist auf eine Ressource mit hoffentlich garantiertem Inhalt.
Das ist Bei Funktionen und Parametern bei dir nicht gegeben.

Da muss ich widersprechen: Eine Pfad verweist auf eine resource ODER eine collection (also eine Liste von Resourcen). Resources sollten einzigartig sein (das meinst du doch mit 'garantiert' oder?), das kann bei collections nicht immer gegeben sein (schon weil resourcen hinzukommen und verschwinden). Oder Zumindest sollten sie das. Und da wären wir auch schon beim Stichwort REST (representational state transfer). Die Technik mit einem Query in ehren hat Sie Ihre Nachteile. Die Motivation meines Ansatzes ist gerade darin begründet keine Querys zu nutzen. Es geht also darum eine collection mit einer Funktion zu modifizieren (z.B. sortieren, filtern, etc.). Um mal ein paar bessere Beispiele zu nennen :

http://www.example.org/blog/filter(author:tim)
(damit würden alle Beiträge des Autors 'tim' aufgelistet)

http://www.example.org/blog/?method=filter&arg1=author&arg2=tim
(wäre frei heraus eine äquivalente URI mit query string)

http://www.example.org/cars/filter(color:blue,type:hatchback)/sort(by:name,to:ASC)
(etwas komplexer : sortierte Auflistung aller blauen Autos mit Fließheck nach dem Namen)

Das ellenlange und unleserliche Äquivalent mit einem query überlasse ich eurer Phantasie.

Nun ich hoffe es macht es euch nicht noch schwerer mir auf die eigentliche Frage nach Problemen bei derart URLs/URIs zu antworten.

Grüße,
stefan

[ChrisB]

Hi,

http://www.example.org/blog/filter(author:tim)
(damit würden alle Beiträge des Autors 'tim' aufgelistet)

Was interessiert mich als Nutzer, dass deine Funktion, die dafür zuständig ist, "filter" heisst?

http://www.example.org/blog/byauthor/tim - das wäre eine Adresse, der ich als humaner Nutzer deutlich den Vorzug geben würde.

http://www.example.org/cars/filter(color:blue,type:hatchback)/sort(by:name,to:ASC)
(etwas komplexer : sortierte Auflistung aller blauen Autos mit Fließheck nach dem Namen)

Auch hier sind sicherlich "schönere" URLs denkbar.

Das ellenlange und unleserliche Äquivalent mit einem query überlasse ich eurer Phantasie.

Ich finde nicht, dass die Klammern das ganze besser lesbar machen, und lang genug ist mir deine Version auch schon.

Das Keyword filter halte ich für gänzlich entbehrlich, es interessiert mich als Nutzer nicht.
color und type könnte man ggf. auch noch rauskürzen, wenn man ihnen feste Positionen zuweist - bei diesem Beispiel vielleicht weniger glücklich, aber in anderen Szenarien mit weniger potentiellen Auswahlmöglichkeiten durchaus. Und andererseite, Auswahlen mit noch mehr Filterkriterien müssen auch nicht unbedingt unter einer "festen" Adresse per GET erreichbar sein, weil sie langsam hinreichend individuell werden - da ist dann POST manchmal die vernünftigere Wahl. Und dem Nutzer kann ich ja immer noch anbieten, bestimmte Filter-Kombinationen in seinem Profil abzulegen, so dass sie später erneut abgerufen werden können.

Nun ich hoffe es macht es euch nicht noch schwerer mir auf die eigentliche Frage nach Problemen bei derart URLs/URIs zu antworten.

Deine eigentliche Frage ist sicherlich legitim; allerdings sollte vor ihrer Betrachtung doch sichergestellt werden, dass man sich nicht bereits vorher "verrannt" hat. Und selbst wenn nicht für dich persönlich und im Moment, so ist diese Diskussion doch für die Allgemeinheit sicherlich von genügend Interesse, um sie nicht einfach abzuwürgen :-)

MfG ChrisB

[Beat]

Was interessiert mich als Nutzer, dass deine Funktion, die dafür zuständig ist, "filter" heisst?

Ich nehme mal die Idee auf, dass die url für eine Stichprobe steht, also ein query darstellt.
hier würde mich /tim nicht befriedigen, weil es etwas über tim, nicht eine stichprobe von seinen Artikeln bezeichnet.

/search/articles/tim

ist hingegen klar. Was ich speichere ist eben nicht die Locator zu einem Inhalt sondern eine Recherche. Und das nimmt mir dann auch gleich die Lust, so etwas zu bookmarken, zu Recht, denn ich möchte den Permalink zum Artikel.

mfg Beat

[ChrisB]

Hi,

Was interessiert mich als Nutzer, dass deine Funktion, die dafür zuständig ist, "filter" heisst?

Ich nehme mal die Idee auf, dass die url für eine Stichprobe steht, also ein query darstellt.
hier würde mich /tim nicht befriedigen, weil es etwas über tim, nicht eine stichprobe von seinen Artikeln bezeichnet.

/search/articles/tim

ist hingegen klar.

Auch nicht weit von meinem Vorschlag, /blog/byauthor/tim, entfernt.
Wie genau man das jetzt ausformuliert, geht weg vom technischen und mehr hin zur Prosa - aber ich denke, beide Vorschläge vermitteln mir als Nutzer schon eine gute Idee, was ich als Inhalt zu erwarten habe.

(Und an der Stelle würde ich mich vielleicht auch gegen einen Doppelpunkt gar nicht so sehr sträuben: /blog/byauthor:tim hat für mich auch seinen Reiz, weil es Funktionalität [Filterung nach Author] und Parameter [hier: das Filterkriterium] *verbindet*, anstatt sie bloss hintereinander als pseudo-Pfadbestandteile aufzulisten, was ohne Kenntnis des Schemas keinerlei Bezug herstellt.)

Was ich speichere ist eben nicht die Locator zu einem Inhalt sondern eine Recherche.

Klares Jein meinerseits :-)
Es referenziert auf eine bestimmte Art von Inhalt, nämlich von Tim verfasste Artikel. Klar ist dieser Inhalt mit der Zeit Veränderungen unterworfen, der Umfang wächst vermutlich an. Und ich werde übermogen, in zwei Wochen oder in einem Jahr nicht mehr das gleiche dort vorfinden, wie aktuell - zumindest nicht mehr an der gleichen Position.

Und das nimmt mir dann auch gleich die Lust, so etwas zu bookmarken, zu Recht, denn ich möchte den Permalink zum Artikel.

Den bekommst du sowieso; die Adresse, über die wir gerade diskutieren, stellt ja nur eine "search query" dar, wie du schon sagtest. [1]
Aber auch daran, genau diese zu bookmarken, habe ich vielleicht ein Interesse - weil ich übermorgen, in zwei Wochen oder einem Jahr damit ganz schnell herausfinden kann, welche neuen Artikel von Tim es gibt.

Die in der Theorie recht simpel und scharf abzutrennenden Einsatzbereiche von GET und POST verschwimmen in der Praxis natürlich etwas.
Aber anstatt mich hier auf ein Dogma zu versteifen, überlege ich doch lieber, was dem Nutzer grösseren Vorteil und Komfort bietet. Und da ist denke ich genau dieses Beispiel, dass ich mich über einen Link öfters mal schnell informieren können möchte, was es von Tim neues gibt, nicht so abwegig.

[1] Wobei hier dem Nutzer transparent gemacht werden muss, dass diese "search query" eben keine permante Adresse zum aktuell zu oberst gelisteten Eintrag ist; der "Permalink" ist separat und prominent genug anzubieten. SOnst wird der "falsche" geboomarked/weitergegeben, und führt in Zukunft eben nicht mehr zum hier explizit gewünschten Inhalt. Ich denke aber, dieses Szenario ist zumindest in der "Blogosphäre" gang und gäbe und damit hinreichend bekannt.)

MfG ChrisB

[sHo]

»» Was interessiert mich als Nutzer, dass deine Funktion, die dafür zuständig ist, "filter" heisst?

Ich nehme mal die Idee auf, dass die url für eine Stichprobe steht, also ein query darstellt.
hier würde mich /tim nicht befriedigen, weil es etwas über tim, nicht eine stichprobe von seinen Artikeln bezeichnet.

/search/articles/tim

Selbst dass wäre zu wenig. Man muss ich schon auf die unterste ebene hinab begeben und (wie software) nicht interpretieren. Ein Beispiel :

/cars/2001

Was ist 2001? Es könnte das Baujahr sein, eine ID einer eindeutigen resource (eines Autos) oder noch mehr.

/cars/yom/2001

Damit könnte man das Baujahr bestimmen, schön und gut. Was erhält man? Eine collection.

/cars/id/32148203

Was erhält man? Eine resource. Gleiche Struktur, andere Ergebnisse. Sehr schlecht!

Funktionen wie ich sie mir vorstelle sollten nur auf collections anwendbar sein und nur eine collection zurückgeben.

/cars
.. eine collection mit allen Autos

/cars/filter(color:blue)
.. eine collection aller Autos der Farbe blau (bzw. des Attributs 'color'=='blue')

Beide letzten collections geben Listen von resourcen wieder, eine resource ist dabei z.B. :

/cars/129823

Nicht sehr schön, weit entfernt von einer für den Nutzer interpretierbare URL aber genau dass, was sie sein sollte : eindeutig.

ist hingegen klar. Was ich speichere ist eben nicht die Locator zu einem Inhalt sondern eine Recherche. Und das nimmt mir dann auch gleich die Lust, so etwas zu bookmarken, zu Recht, denn ich möchte den Permalink zum Artikel.

Da hast du recht! Du bekommst aber auch kein Artikel, sondern eine Liste von Artikeln. Der Artikel selbst wäre dann eindeutig hinterlegt.

[sHo]

Hallo ChriB,

Was interessiert mich als Nutzer, dass deine Funktion, die dafür zuständig ist, "filter" heisst?

So schön es wäre, nach dem Nutzer geht es hier nicht in erster Linie. Schließlich ist der Mensch nicht der einzige Nutzer von URLs/URIs. Nach deiner Ansicht könnte man so vieles zusammenfassen oder ganz streichen. Sicher schaut das besser aus, Eindeutigkeit, Flexibilität und dergleichen würden dabei aber schrecklich vernachlässigt.

http://www.example.org/blog/byauthor/tim - das wäre eine Adresse, der ich als humaner Nutzer deutlich den Vorzug geben würde.

Das klappt bei einem so einfachen Fall, aber was ist mit komplexeren?

color und type könnte man ggf. auch noch rauskürzen, wenn man ihnen feste Positionen zuweist - bei diesem Beispiel vielleicht weniger glücklich, aber in anderen Szenarien mit weniger potentiellen Auswahlmöglichkeiten durchaus.

Die Struktur von Funktionen bzw. Parameter so sehr auf Resourcen zuzuschneiden ist sehr schlecht. Eine einheitlich klare und logische Struktur finde ich unablässig. Andernfalls wäre man ganz schnell wieder beim Ansatz von WSDL.

Und andererseite, Auswahlen mit noch mehr Filterkriterien müssen auch nicht unbedingt unter einer "festen" Adresse per GET erreichbar sein, weil sie langsam hinreichend individuell werden - da ist dann POST manchmal die vernünftigere Wahl.

Ich verstehe was du meinst, ein POST auf eine collection sollte aber dazu dienen eine neue resource anzulegen.

Und dem Nutzer kann ich ja immer noch anbieten, bestimmte Filter-Kombinationen in seinem Profil abzulegen, so dass sie später erneut abgerufen werden können.

Schon aber das ist nicht Sinn der Sache, schließlich soll z.B. auch Software URLs/URIs benutzen können. Und wieder wären wir bei WSDL.

Deine eigentliche Frage ist sicherlich legitim; allerdings sollte vor ihrer Betrachtung doch sichergestellt werden, dass man sich nicht bereits vorher "verrannt" hat. Und selbst wenn nicht für dich persönlich und im Moment, so ist diese Diskussion doch für die Allgemeinheit sicherlich von genügend Interesse, um sie nicht einfach abzuwürgen :-)

Mit der Debatte hatte ich schon gerechnet. Es ist auch gut - es hilft mir mich selbst auch zu hinterfragen. Meinen Standpunkt werde ich aber auch verteidigen keine Frage.

Gruß,
stefan

[Beat]

Die Struktur von Funktionen bzw. Parameter so sehr auf Resourcen zuzuschneiden ist sehr schlecht. Eine einheitlich klare und logische Struktur finde ich unablässig.

Ich finde in query Strings eine einheitliche klare und logische Struktur.
Du hast die Freihit, das ? durch ein anderes zeichen zu ersetzen,
du hast die Freiheit das = durch ein : zu ersetzen.
du hast die Freiheit & durch () zu ersetzen.

Aber als ersten Partner in der Einheitlichkeit hast du Webformulare verloren, und musst fortan zweigleisig verfahren um Userinput! auszulesen.

mfg Beat

[sHo]

»» Die Struktur von Funktionen bzw. Parameter so sehr auf Resourcen zuzuschneiden ist sehr schlecht. Eine einheitlich klare und logische Struktur finde ich unablässig.

Ich finde in query Strings eine einheitliche klare und logische Struktur.
Du hast die Freihit, das ? durch ein anderes zeichen zu ersetzen,
du hast die Freiheit das = durch ein : zu ersetzen.
du hast die Freiheit & durch () zu ersetzen.

Das Zeichen '?' ist reserviert um ein query überhaupt erst einzuleiten und ist im bzw. nach dem Pfad ganz sensibel zu handhaben. Ist die Trennung mit '&' und Zuweisung mit '=' denn ein Quasi-Standard oder wurde das irgendwann fest vorgeschrieben?

Schema://[Benutzer[:Passwort]@]Server[:Port][/Pfad][?Anfrage][#Fragmentbezeichner]

Aber im Grunde hast du Recht - ein query string bietet eine einheitliche und (relativ) übersichtliche Struktur an. Wie aber schon gesagt ist meine Motivation gerade ohne diesen zu arbeiten. Auf dieses für und wieder werde ich jedoch nicht eingehen - Nachteile von queries und die Vorteile durchgehend RESTful umgesetzter Strukturen gibt es im Internet.

Aber als ersten Partner in der Einheitlichkeit hast du Webformulare verloren, und musst fortan zweigleisig verfahren um Userinput! auszulesen.

Nicht zwangsläufig. Am Beispiel eines Kontaktformulars wäre ein POST mit den üblichen Daten auf den Pfad "/contacts" eine durchaus RESTful legitime Umsetzung. Das Formular selbst kann als resource über den Pfad "/contact_form" erreichbar sein. Der Gedanke war aber gut!

Gruß,
stefan

[Beat]

Aber im Grunde hast du Recht - ein query string bietet eine einheitliche und (relativ) übersichtliche Struktur an. Wie aber schon gesagt ist meine Motivation gerade ohne diesen zu arbeiten. Auf dieses für und wieder werde ich jedoch nicht eingehen - Nachteile von queries und die Vorteile durchgehend RESTful umgesetzter Strukturen gibt es im Internet.

Also ich kenne nur das SEO Geraune, welches sich meist um Halbwissen rund um Google rankt.
Es würde mich schon mal interessieren, welche Nachteile du denn in queries siehst. Nicht dass ich dir eine Alternative abschwatzen will, aber es interessiert mich mal mehr als dieses Geraune zu hören.
Um das Argument der schreibfreudigen kurzen Links kanns dir nicht gehen.
Um das gelegentliche Problem von unmaskierten & in Queries auch nicht (das sich elegant umgehen lässt).
Wo ist denn der Vorteil deiner Syntax? oder, warum machen queries Maschinen Probleme?

mfg Beat

[sHo]

Also ich kenne nur das SEO Geraune, welches sich meist um Halbwissen rund um Google rankt.

Stimmt, da kursieren die komischsten Annahmen aber um SEO geht es mir in erster Linie nicht.

Vor allem ist mir der Aspekt der Performanz wichtig. Wie es scheint können viele (wenn nicht alle) caching proxies mit query strings nichts anfangen. Dass heißt ein Großteil der Anfragen heutzutage wird von diesen Proxies ignoriert und müssen direkt vom Server verarbeitet werden. Sicher hat jede halbwegs anständige Anwendung ihren eignen cache hinterlegt aber die Infrastruktur der caching proxies ist quasi überall schon vorhanden - meist also näher am Anfragesteller.

Die RestWiki ist da auch recht interessant, aber leider oft offline, darum hier der Link der gecachte Seite bei google : link

Gruß,
stefan

[Beat]

Vor allem ist mir der Aspekt der Performanz wichtig. Wie es scheint können viele (wenn nicht alle) caching proxies mit query strings nichts anfangen. Dass heißt ein Großteil der Anfragen heutzutage wird von diesen Proxies ignoriert und müssen direkt vom Server verarbeitet werden. Sicher hat jede halbwegs anständige Anwendung ihren eignen cache hinterlegt aber die Infrastruktur der caching proxies ist quasi überall schon vorhanden - meist also näher am Anfragesteller.

Die RestWiki ist da auch recht interessant, aber leider oft offline, darum hier der Link der gecachte Seite bei google : link

Gut dass du das Thema Caching erwähnst.
Cache sind nicht ein Ersatz für deine Datenbank. Sie eigenen sich nicht für Seiten, die über einen querystring Datenbank-Befragung indizieren.
Restfull Seiten geben vor statischer Content zu sein.
Sie verstopfen dadurch Caches unnötig und müssen dann mit CacheControll wiederum bewahrt werden, dasss Datenabfragen gerade in einem schneller wechselnden Datenbestand wieder durchgeführt werden.
Robots (auch ene Art Informationscache) müssen ebenfalls Prioritäten setzen. Darin liegt begründet dass viele kleinere Bots entweder keine Querystrings oder nur solchen mit einer Combo parsen.
Wenn nun diese Bots keine Queries mehr sehen, werden sie irgendwelche urls indexieren, und das eventuell wichtige dazu relativ vernachlässige.

Ich denke, das muss man sich zweimal überlegen ob man Restfull Urls einsetzt. Es könnte ein Schuss in den eigenen Fuss werden.

Und dann komme ich zur Performance. Das Caching ist auf deinem Server am Besten aufgehoben, weil du allein weist, wann content frisch ist.
Den Cache auf ferne Proxies zu verlagern, heisst, den Speicherbedarf reell zu multiplizieren. Ja davon kann dein eigener Server profitieren, aber wenn du dennoch frische Inhalte anbieten willst, bringt es das schlicht nicht.

mfg Beat

[sHo]

Und damit wären wir fernab des eigentlichen Themas bei einer der vielen polarisierenden Grundsatzfragen angelangt. Die eigentliche Frage werde ich wohl dann doch begraben können was? Nungut ..

Cache sind nicht ein Ersatz für deine Datenbank. Sie eigenen sich nicht für Seiten, die über einen querystring Datenbank-Befragung indizieren.

Selbstverständlich sind Caches und Datenbanken zwei verschiedene Paar Schuhe und haben beide ihr spezifisches Einsatzgebiet. Wieso du nun noch Datenbanken ins Spiel bringst kann ich nicht ganz nachvollziehen - das macht das Thema nur komplizierter.

Restfull Seiten geben vor statischer Content zu sein.
Sie verstopfen dadurch Caches unnötig und müssen dann mit CacheControll wiederum bewahrt werden, dasss Datenabfragen gerade in einem schneller wechselnden Datenbestand wieder durchgeführt werden.

Scheinbar hast du schon viele schlechte Beispiele gesehen, das aber gleich blindlings auf alle restful Seiten zu beziehen ist unfair und dumm (entschuldige aber denk mal drüber nach). Eine Seite (oder Resource) gibt aus sich heraus doch nicht vor statisch zu sein nur weil das Prinzip von REST gilt. Wie gesagt kann es auch nicht nur statischen Inhalt geben. Wär ja schlimm, denn das würde heißen es würde keine resourcen hinzukommen oder wegfallen (kurz : es würde sich nie etwas ändern). Ob resources (z.B. halt Seiten) vom cache proxy aufgenommen werden kann man jeder resource (Seite) zuweisen. Wird das nicht oder falsch gemacht, können die caches unnötig verstopfen - der Grund ist aber nicht REST an sich, sondern die Implementierung.

Robots (auch ene Art Informationscache) müssen ebenfalls Prioritäten setzen. Darin liegt begründet dass viele kleinere Bots entweder keine Querystrings oder nur solchen mit einer Combo parsen.
Wenn nun diese Bots keine Queries mehr sehen, werden sie irgendwelche urls indexieren, und das eventuell wichtige dazu relativ vernachlässige.

Das sich robots auf queries eingestellt haben mag sein - es ist jedoch noch lang nicht richtig oder gut, nur weil es gängige Praxis ist. Robots könnten sich auch auf andere Strukturen einstellen lassen, auf diese vielleicht sogar besser. Was robots oder andere agents auf ihren request hin bekommen (also was sie sehen) sollen kann man ebenfalls steuern.

Ich denke, das muss man sich zweimal überlegen ob man Restfull Urls einsetzt. Es könnte ein Schuss in den eigenen Fuss werden.

Wie alles, was man einfach falsch angeht. =)

Und dann komme ich zur Performance. Das Caching ist auf deinem Server am Besten aufgehoben, weil du allein weist, wann content frisch ist.

Dadurch, dass ich das weiß kann ich der resource (Seite) schon mitgeben wann sie verfällt und somit dem Proxy, wie lang er die resource vorhalten kann.

Den Cache auf ferne Proxies zu verlagern, heisst, den Speicherbedarf reell zu multiplizieren. Ja davon kann dein eigener Server profitieren, aber wenn du dennoch frische Inhalte anbieten willst, bringt es das schlicht nicht.

Wieso sollte es nichts bringen? Welchen Intervalle meinst du denn mit 'frisch'? Ein paar Minuten vielleicht? Das kann in manchen Szenarien schon eine halbe Ewigkeit sein und mehrere tausend gleicher Anfragen eingehen. Ein caching lohnt sich schon bei einer einzigen abgefangenen Anfrage, vor allem bei heutigen teilweise sehr komplexen und rechenintensiv erstellten resources (Seiten).

Nichts für ungut. =)

Grüße,
stefan

[hotti]

moin,

http://www.example.org/function/radom(min:3,max:4)

Besser ists, die Parameter aufzuteilen, z.B. so:

http://example.com/calculator.cgi?min=3&max=4

Dann brauchst auch den Parser nicht neu zu erfinden ;-)

Hotte

[Beat]

http://www.example.org/function/radom(min:3,max:4)
Besser ists, die Parameter aufzuteilen, z.B. so:
http://example.com/calculator.cgi?min=3&max=4
Dann brauchst auch den Parser nicht neu zu erfinden ;-)

und dann noch besser:

http://example.com/calculator.cgi?min=3;max=4
                                       ^
minus ein copy-paste Problem

mfg Beat

[hotti]

Moin,

»» > http://www.example.org/function/radom(min:3,max:4)
»» Besser ists, die Parameter aufzuteilen, z.B. so:
»» http://example.com/calculator.cgi?min=3&max=4
»» Dann brauchst auch den Parser nicht neu zu erfinden ;-)

und dann noch besser:

http://example.com/calculator.cgi?min=3;max=4
                                       ^
minus ein copy-paste Problem

Den Witz hab ich nicht verstanden. Kannst Du mir den mal erklären? Büdde ;)

Hotti

[Beat]

»» > http://www.example.org/function/radom(min:3,max:4)
»» Besser ists, die Parameter aufzuteilen, z.B. so:
»» http://example.com/calculator.cgi?min=3&max=4
»» Dann brauchst auch den Parser nicht neu zu erfinden ;-)
und dann noch besser:
http://example.com/calculator.cgi?min=3;max=4
minus ein copy-paste Problem

Den Witz hab ich nicht verstanden. Kannst Du mir den mal erklären? Büdde ;)

Na du kennst du die unmaskierten & die gerade in CMS sehr oft zu beobachten sind. Die vergessen einfach oft Urls richtig zu behandeln.
Mit einem ; Separator hast du da ein Problem weniger.

mfg Beat

[hotti]

hi,

Mit einem ; Separator hast du da ein Problem weniger.

hehe, das ist ja gar kein Witz, das funktioniert, ebend getestet:

QUERY_STRING              x=1;y=2
Parameter

x                         1
y                         2

Hast Du noch einen guten Link dazu, zum Nachlesen meine ich?

Hotte

[Beat]

Hast Du noch einen guten Link dazu, zum Nachlesen meine ich?

http://www.w3.org/TR/1999/REC-html401-19991224/appendix/notes.html#h-B.2.2

mfg Beat

[hotti]

»» Hast Du noch einen guten Link dazu, zum Nachlesen meine ich?

http://www.w3.org/TR/1999/REC-html401-19991224/appendix/notes.html#h-B.2.2

qq(We recommend that HTTP server implementors, and in particular, CGI implementors support the use of ";" in place of "&" to save authors the trouble of escaping "&" characters in this manner.)

Cool ;)
Hotte

[Gunnar Bittersmann]

@@Beat:

»» Hast Du noch einen guten Link dazu, zum Nachlesen meine ich?

http://www.w3.org/TR/1999/REC-html401-19991224/appendix/notes.html#h-B.2.2

• http://forum.de.selfhtml.org/archiv/2006/1/t122672/#m789242

Live long and prosper,
Gunnar