Hallo Tim.

[…]

»»

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

Bei diesen fände ich ein unabhängiges Aufrufen der Funktionalität verwirrend. Hier fehlte die Zuordnung zum jeweiligen Thread / Posting. Daher sollten sie auch genau dort als Link oder Button zu finden sein.

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

Datenverändernde. […]

Gut, kann ich nachvollziehen. Diese benötigen in der Tat normalerweise keine Möglichkeit, die Tätigkeit exakt wiederholen zu können. Unter Umständen ist die jeweilige Ressource nach dem einmaligen Ausführen sogar gar nicht mehr oder in veränderter Form existent, wo ein erneutes Durchführen zu Problemen führen kann.

GET: […] 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.

Dies ist ja bereits heute schon der Fall (Suchabfragen, Live-Filter, etc.) und in meinen Augen auch genau der richtige Einsatzzweck der GET-Methode.

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.

Mangels der Umsetzung von letzteren beiden kann man hier meiner Meinung nach aber auch gut mit der POST-Methode arbeiten. Diese definiert ja schließlich nur, dass Daten übertragen werden. Dass diese Daten auch unter anderem die Erstellung oder Löschung von Daten initiieren können, ist hier nicht relevant. POST bietet nur eine Übertragungsmöglichkeit, die Handlungsmöglichkeiten sind eine Sache der anderen Seite (Server, Backend, …).

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.

/?t=123

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

/?t=123&m=456

Dies ist lediglich eine Sache der Lesbarkeit, umgesetzt wird es hier aber offenbar schon so, wie du es erwartest. Bis auf …

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

… dies. Die Repräsentation wird der Bequemlichkeit halber serverseitig der jeweiligen Konfiguration folgend gespeichert und ist damit von jedem beliebigen Client aus gleich erreichbar.

Aber auch die Feeds werden doch bereits über GET-Parameter für die einzelnen Threads verfügbar gemacht:

/rss/?t=123

/atom/?t=123

Also wird auch dies bereits so durchgeführt, wie du es dir vorstellst.

POST /new       ... um einen neuen Thread abzuschicken

/cgi-bin/user/fo_post

POST /t123/m456 ... um eine Antwort auf ein Posting abzuschicken

Dies würde ich in der Tat ebenfalls begrüßen.

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.

Eben. Zumindest momentan ist noch relevanter Vorteil bei der Nutzung der angemessenen HTTP-Methoden erkennbar, da die weit verbreiteten recht gut alle möglichen Funktionalitäten abdecken können. Dass man das Ganze durch aber weitaus vereinfachen könnte, bedarf zur Erkennung noch Einiges an Zeit. Ich schätze, dass man erst dann über Alternativen nachdenken wird, wenn man an die Grenzen der verbreiteten Methoden stößt. Und dann wird man sicher zuallererst versuchen, das Rad neu zu erfinden, wird unzählige Ressourcen investieren und viele Kosten verursachen. Ein typisches Dilemma.
Wie immer gilt: so bald es wirklich nennenswerte Implementierungen gibt, wird die Verbreitung steigen und die Attraktivität dieser Funktionalitäten erkannt. (Siehe Google → AJAX)

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.

Wenn man sich gleich eine gut durchdachte Schnittstelle schafft, die diese Aufgaben übernehmen kann, erspart man sich in der Tat viel Aufwand. Aber eine solche Schnittstelle will erst einmal entwickelt werden.

Einen schönen Samstag noch.

Gruß, Ashura