Hallo Ashura,

Ist eine Möglichkeit, den Platz sinnvoll zu nutzen, sofern der Aufwand betrieben wurde, auch wirklich alle relevanten Links mit einem Titel zu versehen.

Muss man ja nicht, in meiner Lösung werden Links, für die man keinen Titel braucht, also z.B. rausgehende Verweise trotzdem noch mit URI angezeigt.

Hier hast du aber zeitgleich eine nützliche Funktion wieder unterdrückt: das Anzeigen der URI. Daher wäre ich persönlich in diesem Beispiel dafür, einen Text in der Form „Titel (URI)“ zu erzeugen.

Wenn man auf URIs steht, kann mandas natürlich machen, ja. ;)

Inwiefern genau? Die GET-Methode hat den Vorteil, dass sie ohne große Vorarbeit jederzeit schnell wiederholt werden kann, egal ob durch ein Lesezeichen oder die Browser-History.

Ein paar GET-Links hier aus dem Forum, die datenverändernde Funktionen aktivieren:

Thread als interessant markieren – http://forum.de.selfhtml.org/my/?a=mi&mit=123
Thread ausblenden                – http://forum.de.selfhtml.org/my/?a=d&dt=123
Thread als gelesen markieren     – http://forum.de.selfhtml.org/my/?mv=123
Posting löschen¹                 – http://forum.de.selfhtml.org/my/?t=123&m=123&faa=del&aaf=1
Thread sofort archivieren¹       – http://forum.de.selfhtml.org/my/?t=123&m=123&faa=archive&aaf=1
No-Answer-Flag setzen¹           – http://forum.de.selfhtml.org/my/?t=123&m=123&a=set-na&aaf=1
Thread nicht archivieren¹        – http://forum.de.selfhtml.org/my/?t=123&m=123&a=set-noarchive&aaf=1

Etwas absurd, diese Verweise zu bookmarken, oder? Auch wenn ich damit gespielt habe, Bookmarklets zu erstellen, ja.

Welche Funktionalität hier im Forum sollte deiner Meinung besser per POST genutzt werden?

Datenverändernde. Es muss nicht, aber es erscheint sinnig, denn sie sind schon auf einer niederen Protokollebene eingeplant. Denn: es gibt vieles schon in HTTP. Um mal auszuholen: HTTP definiert Objekte (Ressourcen) und Methoden, die man darauf anwenden kann. In diesem Forumskontext sind Ressourcen zum Beispiel Threads und einzelne Postings. Die könnte man durch diese URIs identifizieren:

Thread:  http://tims-forum.example/t123
Posting: http://tims-forum.example/t123/m456

HTTP definiert nun verschiedene Methoden:

GET: Um eine Repräsentation einer Ressource zu erhalten. Also bei der ersten URI zum Beispiel den Thread in der Listen- oder Nested-Ansicht oder als Ausgangsposting mit Threadbaum. Man erhält konzeptionell immer dieselben Daten, wenn auch in verschiedenen Repräsentationen (HTML, RSS) oder auch diese Repräsentationen in verschiedenen Formen, gesteuert über die GET-Parameter.

POST: Um eine Ressource mit Informationen zu erweitern oder bestehende Informationen zu verändern

PUT: Um eine neues Ressource zu erstellen.

DELETE: Um eine Ressource zu löschen.

(Die Protokoll-introspektiven Methoden CONNECT, HEAD, OPTIONS und TRACE lasse ich mal weg.)

Im Prinzip hat HTTP also alles schon vorhanden, was man so braucht, um Daten zu verwalten, ähnlich dem Akronym CRUD (Create, Retrieve, Update, Delete) bei Datenbanken. Wieso es also nicht einfach nutzen, anstatt die Methoden über nur eine Methode zu tunneln? Im Falle des Forum also zum Beispiel:

GET /t123      ... um eine Repräsentation eines Threads zu erhalten.
GET /t123/m456 ... um eine Repräsentation eines Postings zu erhalten

Welche Repräsentation genau wird dann über Content Negotiation und GET-Parameter geregelt.

POST /new       ... um einen neuen Thread abzuschicken
POST /t123/m456 ... um eine Antwort auf ein Posting abzuschicken

Und obige Aktionen kann man dann ebenso umsetzen. Bzw. eigentlich geht das meiste über POST, nur das Löschen der Admins über DELETE. Hat man auf Server-Seite ein gutes Framework, kann man auch gut umsetzen. Zum Beispiel, im Mini-Webframework web.py (gerade nicht erreichbar) programmiert man nicht imperativ, sondern in Ressourcen (jetzt wieder konkrete Objekte) und deren Methoden:

class ForumsPostig(Object):  
    def GET(self, argumente):  
        tuewas()  
        return repraesentation  
    def POST(self, argumente):  
        tueirgendwasanderes()  
        return repraesentation  
    def DELETE(self, argumente):  
        ...

Man wird also darin unterstützt, die HTTP Methoden auf richtige Methoden richtiger Objekte umzusetzen, anstatt dass man sich die Grundsätzlichkeiten von HTTP ständig neu erarbeiten muss.

Das ist natürlich etwas Architekturträumerei, das zugehörige Buzzword derzeit im Web heisst REST. Wichtig: das ist nicht nur eine Architektur um Seiten im Browser abzurufen, sondern um Anwendungen auf dem Web zu basteln. Web Applications. Man ist also »im Prinzip« universeller, als nur HTML auszuspucken.

Damit steht REST etwas im Gegensatz zu den Architekturen XML-RPC und SOAP - die verschwurbeltes, über POST getunneltes XML benutzen, um Aufrufe von Funktionen übers Web weiterzuleiten. Bei REST operiert man auf Objekten, bei RPC ruft man Funktionen auf. Aber das Web hat in den letzten Jahren mit den Füßen abgestimmt. Es will nicht die erweiteren Funktionen von HTTP benutzen, hey, man kommt ja gut mit GET und POST aus und tunnelt alles darüber. Eine Unterstützung für PUT/DELETE im Apache hinzukriegen ist gelinde gesagt .. schwierig, schon allein wegen Sicherheitsbedenken.

Dabei wäre es so viel leichter gewesen. Etwas Debuggen? Einfach curl benutzen. Schonmal den HTTP-Verkehr von SOAP mitgelauscht? Brr.

Auch hier frage ich dich: Inwiefern? Ob POST oder GET ist doch eigentlich in Bezug auf den Aufwand zum Auslesen der Daten gleich.

Im wesentlichen muss man eben noch zwischen GET und POST unterscheiden und dann über die Daten, die mitgeliefert werden, ob als Parameter oder als Content. Ist nervig, wenn die Alternative eine Funktion für alles ist.

¹ Disclaimer: Ihr braucht die Admin-Funktionen nicht ausprobieren, das setzt eh erfolgreiche HTTP Authentifizierung und Übereinstimmung des Login-Namens mit denen in einer Konfigurationsdatei notierten Login-Namen der Devs vorraus.

Tim