| 

.NET C# Java Javascript Exception

[HTTP] Post gegen Get

Dies ist das Archiv des ehemaligen Forums zum Thema Groovy, Grails, Griffon und Bean Scripting Framework, welches unter groovy-forum.de existierte. Die neue Adresse des Groovy-Forums ist: http://codekicker.de/fragen/themen/groovy.


[HTTP] Post gegen Get

krey - 26.03.2008 17:11
Hallo zusammen,

heute habe ich mich mit einem Softwareentwickler über Möglichkeiten zur Parameterübergabe unterhalten, da bei dem benutzten Oracle IAS Server keine GET Parameter empfangen wurden.
Er sagte mir, dass ich die komplette Applikation auf POST umstellen sollte.

Ich bin mir sicher, dass es schon quasi ein Antipattern ist eine Applikation nur auf Javascript und Post umzustellen (Post Back Pattern wie JSF). Nur fehlten mir schlagkräftige Argumente.
Als Beispiel brachte ich, dass man sich keine Seite bookmarken könnte und das man Artikel die man sich bei Amazon ansieht nicht einfach mit dem Link weitergeben könnte.
Solch eine Situation tritt bei Individualsoftware für Unternehmen bei denen die URL personenbezogene Daten spezifiziert auf die ein anderer Benutzer eh nicht zugreifen darf natürlich nicht auf.

Eigentlich zeigt das GET ja logisch "zeige mir ein Objekt x, der Seite y", denn ich möchte auf eine Ressource direkt über die URL zugreifen. Post ist für das Senden von Datenmengen / Formularen etc. gedacht.

Mir wurde gesagt meine Argumentationskette sei unschlüssig. Durchaus denkbar, denn andere Technologien verwenden HTTP_GET nicht (JSF....). Bei solchen Applikationen befindet man sich meist ein einer "Konversation". Daher hat man eine bestimmte Seitenabfolge die man durchläuft. Ein Vorteil den man sich mit GET sichert, ist die einfache Widerverwendung einer Ressource (beispielsweise eine Telefonnummer anzeigen kann man indem man die Telefonnummernseite mit einem GET parameter der jeweiligen Nummer übergibt), wenn eine Seite solch einen Parameter fordert wird dies erkennbarer als wenn man eine "POST only" applikation baut.

Was fällt euch noch dazu ein? Was ist ein vernümpftiges Design für eine Webapplikation und welche Konzepte sollte man hier verfolgen? Ich persönlich bin immer der Idee nachgegangen mit einem parametrisierten GET eine Ressource zu "holen" und alle anderen Änderungen mit einem POST zu vollziehen.

Grüße, Martin


Re: [HTTP] Post gegen Get

roock - 27.03.2008 08:44
Auch bei Intranet-Anwendung ist GET besser. Auch dort will man bei Zurück und Reload nicht gefragt werden, ob man die Daten nochmal schicken woll. Auch dort ist es praktisch, eine bestimmte Seite Bookmarken oder per E-Mail versenden zu können.

Klar kann im Intranet-Anwendungen auch ohne GET schreiben, man verliert dann halt etwas Flexibilität und Usability.

Und aus meinem letzten JSF-Projekt kann ich sagen, dass die Beschränkung auf POST auch beim Entwickeln nervig ist. Dann dort will man auf jeden Fall Seiten bookmarken etc.

Ich würde die "Beweislast" aber eher andersrum sehen. Dass man sowohl GET wie auch POST verwendet, ist der Default für Webanwendungen (egal ob Internet oder Intranet). Wenn jemand GET nicht erlauben will, dann müsste derjenige das vernünftig begründen.

Stefan


Re: [HTTP] Post gegen Get

krey - 27.03.2008 19:32
Die Begründung wäre doch einfach:
- POST reicht aus.
- Benutzer kann nicht an der URL manipulieren
- Dialoge werden als solche durchlaufen (Conversations), so dass der Benutzer eh nicht auf "zurück" klicken sollte.
- Mit einem Workaround / Servlet Mapping lassen sich auch Bookmarks realisieren.

Ich weiß nicht ob ich POST und GET als Default anerkennen würde. Ein get Request ist ja meist unparametrisiert. (GET www.google.de)...
Hier geht es aber um Parameter in der Kommandozeile. Sinnvoll oder nicht?


Re: [HTTP] Post gegen Get

christian - 27.03.2008 20:33
krey schrieb:
-------------------------------------------------------
> Die Begründung wäre doch einfach:
> - POST reicht aus.

Ja, man kann natürlich alles auf POST beschränken, JSF macht es vor. Aber man natürlich hat das auch Nachteile, die in deinem Fall evtl. wegdiskutiert werden könnten ;-)

> - Benutzer kann nicht an der URL manipulieren

Man darf sich aber nicht darauf verlassen, dass der Benutzer eine POST-Anfrage nicht manipuliert. Von daher ist das kein Argument.

> - Dialoge werden als solche durchlaufen
> (Conversations), so dass der Benutzer eh nicht auf
> "zurück" klicken sollte.

ABER, die Zurück-Schaltfläche ist (nach dem Link) das wichtigste Navigationsinstrument, wie bei verschiedenen Usability-Studien herausgefunden wurde.

> - Mit einem Workaround / Servlet Mapping lassen
> sich auch Bookmarks realisieren.

Elegant ist was anderes.

> Ich weiß nicht ob ich POST und GET als Default
> anerkennen würde. Ein get Request ist ja meist
> unparametrisiert. (GET www.google.de)...
> Hier geht es aber um Parameter in der
> Kommandozeile. Sinnvoll oder nicht?

GET holt Daten ohne, dass etwas auf dem Server verändert wird (von Protokolldateien mal abgesehen) und POST ändert den Zustand auf dem Server - so war es jedenfalls mal gedacht.

Gruß
Christian


Re: [HTTP] Post gegen Get

krey - 28.03.2008 02:33
Okay, ich denke grade letzteres ist am wichtigsten!

GET Parametrisierung ist zur genaueren Benennung einer Ressoruce gedacht.

Was den Zurück Button angeht: Ich könnte auch nicht ohne leben ;)

Natürlich lassen sich auch post Daten verändern, einen "richtigen" Schutz gibt es nur auf der Serverseite. Nur ein Benutzer neigt schneller dazu die URL zu ändern, als mit Test/Debug Tools die Post Daten zu modifizieren oder ein POST zu fälschen.


Stelle deine Groovy-Frage jetzt!


Diese Seite zeigt den Thread "[HTTP] Post gegen Get" der ehemaligen Webseite groovy-forum.de, welche durch einen Serverunfall zerstört wurde. codekicker.de hat viele Konversationen über die beliebte Programmiersprache Groovy und zugehörige Frameworks wie das Grails-Framework retten können.

Hast Du eine Frage zum Thema Groovy, Grails oder allgemein Java? Viele ehemalige groovy-forum.de Mitglieder beantworten dir auf codekicker.de deine Frage! Stelle jetzt eine Frage!

Viele weitere Diskussionen zu Grails und Groovy befinden sich auf der Threadübersicht des alten groovy-forum.de.