Frage zu HTTP Post response

Also an dem JS Code von oben ist erst mal kein Grund ersichtlich der 
dazu führt das die Seite komplett neu geladen wird. Die Antwort die dein 
ESP zurückgibt wird einfach verworfen.
Im Übrigen kannst du diesen ActiveX Mist weglassen - wenn du nicht 
gerade einen IE der Version von vor 10 Jahren verwendest.

Sascha

Thomas schrieb:
> Aktuell
> ist es nämlich so, dass der ESP die POST Request mit Code "200 OK"
> quittiert. Dann habe ich aber nach Verschieben des Reglers eine blanko
> (also weiße) Seite im Browser.

Antworte mit "204 No Content".

https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/204
>> The HTTP 204 No Content success status response code indicates
>> that the request has succeeded, but that the client doesn't need
>> to go away from its current page

sid schrieb:
> websockets halte ich für Deine Anwendung für überflüssig,
kommt darauf an was der Schieberegler auslösen soll - wenn ich damit die 
Helligkeit eines LED-Strips regeln will, dann sind Websockets genau die 
Richtige Wahl. Clientseitig ist das kaum aufweniger, auf der Serverseite 
natürlich schon.

Sascha

POST ist auch die falsche Methode, da du keine Ressource anlegst! Der 
Server Antwortet also schon mal falsch -> 201(Created)

PUT wäre die richtige Methode...

Kommt drauf an wie man das löst...

Wenn man den Wert mit dem Regler einstellt und dann einen "SET" Button 
triggert um die Anfrage zu senden geht das auch so...

Bei jeder Wertänderung die Anfrage zu schicken geht auch, überfordert 
aber ewt. den Server auf dem ESP.

Websockets weißt den Webserver an das Protokoll zu wechseln und welches 
nehmen wir dann da für die Aufgabe ???   Im Prinzip entsteht das selbe 
Problem...

Profis lösen das anderes ;)... Sie senden z.Bsp nur alle 300ms zwischen 
werte und interpolieren diese dann im eigentlichen LED Controller. Dann 
löst nicht jeder Wechsel der Werte ein Request aus...

Mit Polling kommt auch recht weit, so 300ms sind meist ausreichend und 
für den Server kein Problem.

Was du aber noch beachten solltest,  es ist immer nur möglich eine 
Anfrage mit Ajax zu senden. So lange wie man auf eine Anfrage wartet ist 
das blockiert. Klingt erst mal nicht weiter schlimm. Aber wenn du zwei 
Regler gleichzeitig schiebst und getrennt verarbeitest kommt das zum 
tragen. Also alle Objekte abfragen und zyklisch senden wenn sich was 
ändert. Wie ich das schon meinte....

Krapfenzüchter schrieb:
> Das hier ist die Referenz
> https://www.rfc-editor.org/info/rfc7230

Schau lieber einen RFC weiter, hier:

https://www.rfc-editor.org/info/rfc7231

Da gehts um "Semantics and Content", und Section 4.3. befasst sich mit 
POST und PUT incl. Erklärungen.

POST:
"Providing a block of data, [...]to a data-handling process"

passt.

PUT:
"The PUT method requests that the enclosed entity be stored under the 
supplied Request-URI. If the Request-URI refers to an already existing 
resource, the enclosed entity SHOULD be considered as a modified version 
of the one residing on the origin server. If the Request-URI does not 
point to an existing resource, and that URI is capable of being defined 
as a new resource by the requesting user agent, the origin server can 
create the resource with that URI. If a new resource is created, the 
origin server MUST inform the user agent via the 201 (Created) response. 
If an existing resource is modified, either the 200 (OK) or 204 (No 
Content) response codes SHOULD be sent to indicate successful completion 
of the request"

Ok... Farbwert als Entity... Neu-Anlegen eher weniger, aber als Update 
zum vorhandenen Farbwert... kann man auch durchgehen lassen.

Aber im Endeffekt sind das alles "SHOULD"-Regelungen. Du kannst deinen 
Farbwert auch
per GET oder OPTIONS oder DELETE oder sonstwas übertragen, per Parameter 
in der URL, per Header-Feld oder sonstwie.
Ist dann zwar "unschön" und "Frickelei", aber die HTTP-Polizei kommt 
nicht vorbei und nimmt dich mit.

Nö...

GET darf die Ressource auf keinen Fall ändern! Das wäre ein klarer 
Verstoß gegen alle Regeln, das aus gutem Grund.

Der HTTP Client erwartet immer eine Antwort vom Server... Da machst dann 
mit AJAX eine Bauchlandung da dass Fenster blockiert.

Mit Murks fängt man gar nicht erst an.....

Marco H. schrieb:
> GET darf die Ressource auf keinen Fall ändern! Das wäre ein klarer
> Verstoß gegen alle Regeln, das aus gutem Grund.

Es ist ein Verstoß gegen "best practices", aber durchaus kein 
unüblicher.

Erinnert sich noch jemand an die Webseiten-Besucherzähler-GIFs, die in 
den 90ern populär waren? Die waren per IMG-Tag eingebunden, wurden per 
GET vom Server geholt, und trotzdem haben sie bei jedem Aufruf einen 
Besuch weitergezählt.

Lieber moderner?

Mach eine beliebige Nachrichten/Zeitungs-Webseite ohne Werbeblocker auf, 
und zähl nach wieviele Tracking-Pixel und Werbe-Scripte da per GET 
geladen werden.
Dann überleg warum die das wohl machen, wenn dabei keine Daten verändert 
werden sollen.


Am Ende will der TE schließlich keine Clean-REST-API bereitstellen um 
damit einen Schönheitswettbewerb zu gewinnen, sondern einfach nur seinen 
ESP per Webseite fernsteuern.

Sascha W. schrieb:
> sid schrieb:
>> websockets halte ich für Deine Anwendung für überflüssig,
> kommt darauf an was der Schieberegler auslösen soll - wenn ich damit die
> Helligkeit eines LED-Strips regeln will, dann sind Websockets genau die
> Richtige Wahl.

Nein, eigentlich nicht. Websockets sind dann sinnvoll, wenn serverseitig 
ein Event ausgelöst wird, weil der Server das Event dann über den 
Websocket pushen kann, und unser Client dann nicht ständig den Server 
pollen muß.

Hier wird das Event -- also: das Verstellen des Schiebereglers -- aber 
clientseitig ausgelöst. Daher kann es einfach via AJAX an den Server 
gesendet werden, und dieser schickt dann eine Bestätigung (zum Beispiel 
mit dem neu gesetzten Wert). Websockets belegen nur serverseitige 
Ressourcen, haben in diesem Anwendungsfall allerdings IMHO keine 
nennenswerten Vorteile.

Thomas schrieb:
> Ich werde heut Nachmittag mal die 204 ausprobieren, das wäre in der Tat
> das einfachste.

IMHO wäre es das Einfachste, es richtig zu machen: ein JS-Framework (wie 
etwa JQuery) zu benutzen und das Ergebnis Deines Requests dann 
clientseitig zu verarbeiten. Damit kannst Du auf eventuelle Fehler 
reagieren oder den Erfolg Deiner Aktion wieder auf Deinen Schieberegler 
anwenden.

Ich sehe auch irgendwie nicht, daß Du einen "richtigen" XMLHttpRequest 
machst. Denn der würde komplett über Java- / ECMAScript laufen und die 
normale Reaktion bei der Übertragung eines HTML-Formulars -- Deinen 
Reload -- gar nicht anstoßen.

> Da die "Sicherheit" hier durch das Netzwerk (hier mit WPA-2
> verschlüsselt) kommt, es sich tatsächlich um eine LED Steuerung handelt,
> welche aber keinerlei zeitkritischen Aspekte hat, wird das denke ich
> auch locker reichen.

Das... also... klar, einerseits ist eine LED-Steuerung wohl meistens 
nicht kritisch, aber andererseits könnte ein Angreifer bei einem 
weiteren Ausbau Deiner Steuerung Deine Beleuchtung so ein- und 
ausschalten, daß vorerkrankte Personen (Gäste?) dabei einen 
epileptischen Anfall erleiden könnten. Denn die WPA2-Verschlüsselung 
schützt natürlich nur die Strecke zwischen Accesspoint und Client, 
während die Strecke vom Accesspoint zum Steuerungsrechner ungeschützt 
bleibt.

sid schrieb:
> Marco H. schrieb:
>> POST ist auch die falsche Methode, da du keine Ressource anlegst! Der
>> Server Antwortet also schon mal falsch -> 201(Created)
>>
>> PUT wäre die richtige Methode...
>
> HUST!
>
> was Du meinst heisst GET nicht PUT und allein dieser Lapsus zeigt
> deutlich wie wenig Du davon verstehst ;)

räusperhüstel Entschuldige bitte, aber Marco hat vollkommen Recht. PUT 
existiert und ist für genau die Dinge vorgesehen, die Marco beschreibt. 
Vielleicht magst Du mal [1] lesen, wenn Du der englischen Sprache 
mächtig bist. Und nein, auch wenn dort von REST-APIs gesprochen wird, 
gilt der HTTP-Standard natürlich primär für HTTP.

[1] https://restfulapi.net/rest-put-vs-post/

Websockets sind geeignet, um automatisch vom Server benachrichtigt zu 
werden (genauso wie hängende HTTP-Anfragen). Nachteil: Die 
TCP-Verbindung zum Server bleibt dauerhaft bestehen, kostet auf dem ESP 
also Ressourcen, die dieser nicht hat.

Sinnvoll ist also tatsächlich ein Request-Response-Verfahren, wie 
klassisches HTTP mit POST (Zustand setzen) plus Rückgabewert und GET 
(Zustand abfragen), um die Webseite initial clientseitig rendern zu 
können.

Das ist auf dem ESP auch die einfachste Variante, das zu implementieren, 
es ist serverseitig stateless und schnell genug.

Sheeva P. schrieb:
> Sascha W. schrieb:
>> sid schrieb:
>>> websockets halte ich für Deine Anwendung für überflüssig,
>> kommt darauf an was der Schieberegler auslösen soll - wenn ich damit die
>> Helligkeit eines LED-Strips regeln will, dann sind Websockets genau die
>> Richtige Wahl.
>
> Nein, eigentlich nicht. Websockets sind dann sinnvoll, wenn serverseitig
> ein Event ausgelöst wird, weil der Server das Event dann über den
> Websocket pushen kann, und unser Client dann nicht ständig den Server
> pollen muß.
kann man sehen wie man will, jedenfalls ist die Verzögerung beim Ändern 
des Schiebereglers wesentlich geringer/nicht vorhanden. Des weiteren 
kann bei mehreren verbundenen Clients der von einem Client geänderte 
Wert auch auf den anderen angezeigt werden. Der Ressourcenverbrauch für 
eine offene TCP-Verbindung sollte sich in Grenzen halten. Zigfache 
HTTP-Anfragen beim ändern des Wertes brauchen wesentlich mehr Ressourcen 
(ja - natürlich nur in dem Moment).

Sascha

sid schrieb:
>> POST is NOT idempotent.

Pardon, aber welchen Teil davon hast Du nicht verstanden?

Sascha W. schrieb:
> Sheeva P. schrieb:
>> Websockets sind dann sinnvoll, wenn serverseitig
>> ein Event ausgelöst wird
>
> kann man sehen wie man will,

Nicht so richtig...

> Des weiteren
> kann bei mehreren verbundenen Clients der von einem Client geänderte
> Wert auch auf den anderen angezeigt werden.

Reden wir noch über ACID oder schon von CAP? ;-)

Sheeva P. schrieb:
> sid schrieb:
>>> POST is NOT idempotent.
>
> Pardon, aber welchen Teil davon hast Du nicht verstanden?

unabhängig von POST/PUT/PATCH/GET/Websocket: Wo will man in einer 
Lampen-Steuerung Idempotency?

Geplante Obsoleszenz? "Sorry, Helligkeitstufe 75% wurde bereits 
verwendet, und kann nicht neu eingestellt werden. Bitte kaufen sie eine 
neue Lampe"

Was, sie wollten den "Heller"-Knopf nur einmal drücken? Egal, dank 
idempotency ist es ja egal ob das einmal oder 100mal war. Darum kann die 
Lampe nur 0% und 100%.

Soll jetzt bei jedem Befehl noch eine Request-ID mitgesendet werden, 
damit die Lampe prüfen kann ob es eine Wiederholung war oder nicht?


Und wieso überhaupt "REST"? Nur weil das grad Hip ist?
Darf ich RPC ins Buzzword-Bingo werfen? Die Clients rufen die "Setze 
Helligkeit"-Prozedur der Lampe remote auf? Oder ist RPC zu altmodisch?

sid schrieb:
> Sheeva P. schrieb:
>> sid schrieb:
>>>> POST is NOT idempotent.
>>
>> Pardon, aber welchen Teil davon hast Du nicht verstanden?
> und wie sieht's bei Dir aus?
> Was ist daran nicht zu verstehen, daß man idempotency überhaupt nicht
> braucht?
> und sie falls man so dumm ist zu glauben man bräuchte sie,
> sie mit ner simplen Abfrage emulieren kann?
> Was hast Du daran nicht verstanden?

Danke für den Hinweis, aber... ich hab' das schon sehr gut verstanden. 
Im Grunde gibt es da viele Möglichkeiten, Dinge zu tun: eine richtige 
und viele flashce.

Das HTTP-Protokoll ist ein Standard. Man kann sich dran halten. Man muß 
aber nicht. Mein -- ganz persönlicher -- Ratschlag ist, sich daran zu 
halten. Von vorneherein.

Warum? Im Prinzip kostet das einerseits (fast) nichts, garantiert aber 
andererseits ein hohes Gut. Nämlich die Zukunftsfähigkeit Deiner 
Software.

Muß man nicht wichtig finden. Kann man aber. ;-)

Sheeva P. schrieb:
> Das HTTP-Protokoll ist ein Standard. Man kann sich dran halten. Man muß
> aber nicht. Mein -- ganz persönlicher -- Ratschlag ist, sich daran zu
> halten. Von vorneherein.

Und HTTP Sagt: "POST" ist an der stelle das Richtige. GET auch. PUT 
auch.

Was du uns verkaufen willst ist "REST". Das ist eine zusätzliche Schicht 
zwischen HTTP und Applikation.

Nur weil REST auf HTTP aufsetzt, bedeutet das nicht im Umkehrschluss 
dass alles legale HTTP auch REST sein muss.

Sonst, analog deiner Logik: Youtube setzt auf HTTP auf. D.H. die 
Fernbedienung sollte ein YT-Video in der gewünschten Helligkeit 
hochladen, die Lampe hat den Kanal abonniert und folgt dem neuestem 
Video.

Sheeva P. schrieb:
> garantiert aber
> andererseits ein hohes Gut. Nämlich die Zukunftsfähigkeit Deiner
> Software.

Youtube ist älter als REST. Baust du jetzt alle deine Schnittstellen auf 
"Datentransfer via Youtube" um? Nein? Warum denn nicht? Ist doch ein 
hohes Gut!

Man kann auch einfach ein zur Anwendung passendes Werkzeug wählen. Wenn 
das Poster an die Wand soll, reicht Klebeband, auch wenn vier Dübel 
tragkräftiger und zukunftsfähiger sind.

Εrnst B. schrieb:
> Sheeva P. schrieb:
>> Das HTTP-Protokoll ist ein Standard. Man kann sich dran halten. Man muß
>> aber nicht. Mein -- ganz persönlicher -- Ratschlag ist, sich daran zu
>> halten. Von vorneherein.
>
> Und HTTP Sagt: "POST" ist an der stelle das Richtige. GET auch. PUT
> auch.

Red' doch bitte keinen Unsinn, sondern lies den einschlägigen Standard. 
Den findest Du hier: [1]. Direkt in der Sektion davor findest Du 
übrigens den Standard für POST.

> Was du uns verkaufen willst ist "REST". Das ist eine zusätzliche Schicht
> zwischen HTTP und Applikation.

Dann verlinke doch bitte ein RFC für dieses REST, aus dem das von Dir 
Behauptete hervorgeht. Vielen Dank, ich harre gespannt.

Nebenbei bemerkt ist REST nur ein Buzzword für etwas, das die 
HTTP-Standards schon seit Ewigkeiten vorsehen. Außerdem ist es keine 
zusätzliche Schicht, sondern eine Technik, um saubere Schnittstellen zu 
gestalten.

In der Wissenschaft gibt es zwar immer noch einen Disput darüber, ob 
REST zwingend an HTTP gebunden sein muß. Die Dissertation von Roy Thomas 
Fielding aus dem Jahr 2000, für die er REST entwickelt und in der er es 
veröffentlicht hat, deutet das zwar an. Und in der Tat ist HTTP 
besonders gut für REST geeignet, gerade weil es im Prinzip eine API für 
serverseitige Ressourcen bereitstellt und deswegen bereits die passenden 
Verben (Request-Methoden) mitbringt. Aber grundsätzlich lassen sich die 
Prinzipien von REST-APIs auch ohne HTTP implementieren.

> Nur weil REST auf HTTP aufsetzt, bedeutet das nicht im Umkehrschluss
> dass alles legale HTTP auch REST sein muss.

Siehe, was Du behauptest, entspricht nun einmal leider NICHT dem 
HTTP-Standard. Und wenn man eine neue Software entwickelt, ist es immer 
eine hervorragende Idee, die einschlägigen Standards einzuhalten. Und im 
Grunde genommen ist es auch bei alter Software immer eine gute Idee, sie 
immer mal wieder an die Weiterentwicklung der einschlägigen Standards 
anzupassen.

Fakt ist, daß es neben GET-Requests -- die, wie der Name schon sagt, 
nicht dazu gedacht sind, Daten auf den Server *hoch*zuladen, die 
Parameter dienen nur zur genaueren Beschreibung der angeforderten 
Ressourcen -- im HTTP-Standard eben auch POST- und PUT-Requests gibt, 
die durchaus einen ähnlichen, aber nun einmal nicht denselben Zweck 
haben.

Das ist nun einmal der geltende HTTP-Standard, ob es Dir gefällt oder 
nicht. Das ist auch nicht erst seit gestern so, also nicht erst seit 
RFC7231 vom Juni 2014, sondern war auch schon im Vorgänger RFC 2608 zu 
HTTP/1.1 vom Januar 1997 so, wie Du in [3] nachlesen kannst, auch hier 
ist der Text zu POST in der Sektion direkt vor der verlinkten. Und, ja, 
sogar in RFC 1945 vom Mai 1996 war das schon so definiert, wie Du unter 
[4] für die Methode POST sowie unter [5] für PUT nachlesen kannst -- 
unter HTTP/1.0 war PUT noch eine optionale Erweiterung und steht daher 
im Anhang, aber mit genau derselben Erklärung über die Unterschiede 
zwischen PUT und POST wie in den späteren Versionen des HTTP-Standards.

Das ist also alles nicht neu und war sogar schon lange vor Youtube da, 
die IIRC zu Anfang des Jahres 2005 online gegangen sind. Daß Du und 
viele andere Menschen (mich eingeschlossen) diese Requesttypen bisher 
falsch benutzt haben, ändert leider nichts daran, daß das der geltende 
HTTP-Standard ist. Mit REST hat das nicht viel zu tun, alldieweil REST 
ja ohnehin vornehmlich ein modernes Buzzword für etwas ist, das im 
HTTP-Standard schon seit ewigen Zeiten genau so vorgesehen ist.

Es ist im Übrigen auch kein unüberwindbarer Aufwand, diese Dinge einfach 
richtig zu machen. Im Gegenteil. Und es kommt jedem zugute, der zum 
Beispiel AJAX nutzen will, zusätzlich zur Website vielleicht einmal eine 
API anbieten, oder sogar einfach nur mehrere Websites haben möchte (zum 
Beispiel eine Desktop- und eine mobile Version), die von demselben 
Datenbackend bedient werden.

Deswegen geht mir leider jedwedes Verständnis dafür ab, warum Du Dich so 
dagegen sträubst und so haarsträubende und fadenscheinige Begründungen 
dafür anführst. Bis jetzt kann ich mir das nur so erklären, daß Du sowas 
bisher aus Unkenntnis falsch gemacht hast und es jetzt partout nicht 
wahrhaben willst, weil nicht sein kann, was nicht sein darf. Aber auch 
wenn ich damit Deine persönlichen Gefühle verletzte, was mir aufrichtig 
leid täte, ist und bleibt der HTTP-Standard, was und wie er ist. Bis er 
irgendwann von einer neuen Version abgelöst wird, jedenfalls... ;-)

> Sonst, analog deiner Logik: Youtube setzt auf HTTP auf. D.H. die
> Fernbedienung sollte ein YT-Video in der gewünschten Helligkeit
> hochladen, die Lampe hat den Kanal abonniert und folgt dem neuestem
> Video.

Da ist es aber ganz schön komisch, daß die Youtube-API das ebenfalls 
haargenau so handhabt, wie im von mir unter [1] verlinkten RFC 
beschrieben. Das kannst Du gern  unter [2] in der offiziellen 
API-Dokumentation von Google nachlesen.

> Youtube ist älter als REST.

Nein, die Dissertation von Roy Thomas Fielding ist aus dem Jahr 2000, 
Youtube kam dagegen erst im Jahr 2005.

> Baust du jetzt alle deine Schnittstellen auf
> "Datentransfer via Youtube" um? Nein? Warum denn nicht? Ist doch ein
> hohes Gut!

Für Youtube mache das nicht ich, sondern Google. Wie gesagt, schau unter 
[2]. Ich wüßte auch nicht, was ein "Datentransfer via Youtube" sein, 
oder warum ich sowas benutzen sollte. Youtube ist ja nicht einmal ein 
Standard und Dein "Argument" nur eine Strohpuppe, die Du gern wieder mit 
nach Hause nehmen darfst. Danke.

[1] https://tools.ietf.org/html/rfc7231#section-4.3.4
[2] https://developers.google.com/youtube/v3/docs
[3] https://tools.ietf.org/html/rfc2068#section-9.6
[4] https://tools.ietf.org/html/rfc1945#section-8.3
[5] https://tools.ietf.org/html/rfc1945#appendix-D.1.1

sid schrieb:
> AAABer das hat mit dem PUT BLÖDSINN nichts zu tun,
> denn PUT ist hier der falsche weg..

PUT ist kein Blödsinn, und hier genau der richtige Weg.

> braucht es zu NIX, zu garnix, idempotency ist so unnötig wie ein
> akustisches Signal
>
> klar kann man das so lösen... macht aber keinen Sinn und ist 100%ig
> unnötig.

Du solltest vielleicht ein bisschen weiter denken...

> eine simple Anfrage nach Licht an oder aus erstellt keine ressource,
> die ressource besteht schon lange (die Lampe ist im system)
> die wiederholbarkeit der Anfrage ist also vollständig irrelevant.

Das gilt in der Praxis nur für Lampen, die genau zwei Zustände haben: an 
und aus. Möglicherweise ist Dir allerdings entgangen, daß es 
mittlerweile Lampen gibt, die wesentlich mehr Zustände abbilden können, 
etwa die HUE "Color & White Ambiance" von Phillips, die 16 Millionen 
zustände abbilden können.

Bei derartigen Lampen gibt es im Prinzip zwei Möglichkeiten, zum 
Beispiel den Rot-Anteil der Lichtquelle zu erhöhen, nämlich einmal indem 
man den aktuellen Wert inkrementiert (Read, Increment, Write) oder indem 
man, unabhängig vom Ausgangswert,  einen Absolutwert setzt. Im zweiten 
Fall ist alles gut, aber wenn -- aus welchen Gründen auch immer, 
Netzwerke sind unsichere Dinger, Funknetzwerke noch mehr -- mehrere 
gleiche inkrementelle Requests eingehen und vom Server verarbeitet 
werden, dann hast Du hinterher einen falschen Farbwert. Von einem 
falschen Farbwert einer Lampe wird die Welt zwar sicherlich nicht 
untergehen, aber was ist, wenn künftig beispielsweise ein Herd, ein 
Ofen, eine Heizung, ein Kühl- oder Eisschrank an das System 
angeschlossen werden?

Sheeva P. schrieb:
> sondern lies den einschlägigen Standard.

https://www.rfc-editor.org/info/rfc7231
Sektion 4.3.3.
Erster Anwendungsfall für POST:
>> Providing a block of data, such as the fields entered into an HTML
>> form, to a data-handling process;

Was will der TE? Ein HTML-Formular mit Schieberegler, die eingegeben 
Daten an einen Prozess weitergeben, der daraus (z.B.) einen PWM-Wert für 
die Lampensteuerung erzeugt.

Du willst Sektion 4.3.4, PUT. Ja, das passt AUCH. Die vorherige 
Sektion wird dadurch nicht ungültig.

Und GET ginge sogar auch. Die RFC erlaubt ausdrücklich Nebeneffekte (wie 
"Helligkeit einstellen") bei GET, solange sie die Rückgabe nicht 
beeinflussen. Caching könnte aber stören.

Das ist nun einmal der geltende HTTP-Standard, ob es Dir gefällt oder
nicht.

Sheeva P. schrieb:
> Dann verlinke doch bitte ein RFC für dieses REST,

Brauch ich nicht, hast du ja selber gefunden:

Sheeva P. schrieb:
> ... die Dissertation von Roy Thomas Fielding ...

Dann solltest du ja den Unterschied zwischen HTTP und REST verstehen.

REST ist, einfach gesagt, nur ein Satz Richtlinien, wie man die 
Möglichkeiten von HTTP REDUZIERT, um damit "schöne" APIs zu bauen.

Eine Lampen-API mit "POSTe Wert hin, Helligkeit wird sofort eingestellt" 
ist so simpel, elegant und straightforward, das wird durch die 
REST-Richtlinien nicht besser oder schöner.

Und nein, ich bin kein genereller Gegner von REST. Ich habe selber 
Services mit REST-Schnittstelle am laufen die Transaktionen über einige 
Mio €/Jahr abwickeln.

Εrnst B. schrieb:
> Du willst Sektion 4.3.4, PUT. Ja, das passt AUCH. Die vorherige
> Sektion wird dadurch nicht ungültig.

Es paßt vor allem besser, und wie Du selbst ja schon weiter oben 
erwähnt hast: genau das wird vom Standard empfohlen (SHOULD).

> REST ist, einfach gesagt, nur ein Satz Richtlinien, wie man die
> Möglichkeiten von HTTP REDUZIERT, um damit "schöne" APIs zu bauen.

Naja... ich würde eher von einer "Anwendung" als von einer "Reduktion" 
sprechen.

> Eine Lampen-API mit "POSTe Wert hin, Helligkeit wird sofort eingestellt"
> ist so simpel, elegant und straightforward, das wird durch die
> REST-Richtlinien nicht besser oder schöner.

Aber richtiger, und genau das ist mein Punkt.

> Und nein, ich bin kein genereller Gegner von REST. Ich habe selber
> Services mit REST-Schnittstelle am laufen die Transaktionen über einige
> Mio €/Jahr abwickeln.

Dann verrat' mir doch bitte, warum Du (und andere, ausgenommen "sid", 
der PUT bis vor Kurzem ja noch nicht einmal kannte und mit GET 
verwechselt hat) so sehr darauf beharrt, Euch nicht an den einschlägigen 
Standard und seine Empfehlung zu halten. Ist ja sogar etwas weniger 
Tipparbeit und entlastet das Netzwerk...

Berufsberater schrieb:
> Für diese Furzanwendung oben ist es scheissegal was man hier nutzt, das
> entscheidet der Entwickler selbst, solange es funktioniert juckt das
> keinen ob das REST-konform oder den HTTP-Empfehlungen entspricht oder
> nicht.

Das ist zwar nicht falsch, aber sei mir bitte nicht böse: ich befürchte, 
genau wegen dieser Einstellung gibt es so viel schlechte Software auf 
dieser Welt.

Die Einstellung impliziert nämlich, daß der Anwendungsfall konstant ist. 
Leider wird Software aber meistens irgendwann weiterentwickelt. Und wenn 
man dann von Anfang an gepfuscht hat, muß man entweder um den eigenen 
Pfusch herumpfuschen, oder man macht die ganze Sache eben neu, aber 
richtig. Leider fallen einem solche Schwierigkeiten jedoch häufig erst 
spät auf, und dann ist der Aufwand einer Neuentwicklung zu groß, 
weswegen man sich das erspart und weiterpfuscht... und im Laufe der Zeit 
immer mehr Aufwand betreiben muß, um mit dem anfänglichen Pfusch 
klarzukommen.

Wäre es da denn nicht viel einfacher, es einfach gleich richtig zu 
machen? Ich meine, die Autoren eines Standards machen sich ja schon 
Gedanken darüber, was sie in ihren Standard hineinschreiben, natürlich 
auch über ihre Empfehlungen. Das machen die nicht, damit wir hier mehr 
oder weniger akademische Diskussionen führen können, sondern weil sie 
sich etwas dabei gedacht haben... nämlich, wie man es richtig macht.

Oh, Edit: und natürlich ist es auch eine Art von Dokumentation des 
eigenen Code, wenn man die richtigen und empfohlenen Methoden benutzt. 
Wenn man in ein, zwei oder fünf Jahren noch eine neue Funktionalität 
hinzufügt und dazu seinen eigenen alten Code liest, erkennt man viel 
besser, was da passiert und warum.

Sheeva P. schrieb:
> Dann verrat' mir doch bitte, warum Du [..] so sehr darauf beharrt, Euch nicht an
> den einschlägigen Standard und seine Empfehlung zu halten.


u.A. weil es Empfehlungen primär für Server-to-Server Kommunikation 
sind, die Anwendung hier aber explizit Webbrowser-To-Server ist.

Der Webbrowser kann einen gültigen POST-Request zum Setzen der 
Lampenhelligkeit auch ganz ohne Javascript absetzen, ein '<form 
method="PUT">' gibt es hingegen nicht.

Εrnst B. schrieb:
> Sheeva P. schrieb:
>> Dann verrat' mir doch bitte, warum Du [..] so sehr darauf beharrt, Euch nicht 
an
>> den einschlägigen Standard und seine Empfehlung zu halten.
>
> u.A. weil es Empfehlungen primär für Server-to-Server Kommunikation
> sind, die Anwendung hier aber explizit Webbrowser-To-Server ist.
>
> Der Webbrowser kann einen gültigen POST-Request zum Setzen der
> Lampenhelligkeit auch ganz ohne Javascript absetzen, ein '<form
> method="PUT">' gibt es hingegen nicht.

Das wäre ein valider Punkt und ich hätte auch gar nichts gesagt, wenn 
der TO nicht ausgerechnet das Folgende geschrieben hätte:

Thomas schrieb:
> Nun habe ich auf dieser "Website" einen Schieberegler, welcher mittels
> Script auf onChange ausgelesen wird. Dieser Wert wird dann mittels Post
> zum ESP geschickt. Dieser wertet diesen Wert dann aus usw. Auch das ist
> korrekt implementiert...

Also zu Deutsch: er hat schon ein Java-/ECMAScript, das den Wert 
ausliest. Dadurch ist er in der komfortablen Situation, die Daten ganz 
einfach per AJAX zum Server PUTten zu können, was automatisch auch sein 
Rückgabeproblem löst. Mit jQuery ginge das sehr einfach und effizient 
mit extrem wenig Code -- und auch noch asynchron, wenn man das möchte.

1

$.ajax({

2

  url: '/set/bulb1/',

3

  type: 'PUT',

4

  data: "hue=15",

5

  success: function(data) {

6

    alert('Hue was set.');

7

  },

8

  error: function(data) {

9

    alert('ERROR: Could not set Hue. Please see error logs.');

10

  }

11

});

Wenn man es absolut richtig machen wollte, würde man natürlich in der 
Antwort des Servers wieder den aktuellen Wert der Helligkeit zurückgeben 
und ihn in den success- und error-Callbacks auf den Schieberegler 
zurücksetzen. Dadurch böte sich außerdem gleich die Gelegenheit, ein 
paar... "Schnellzugriffsknöpfe" für voreingestellte Helligkeitswerte wie 
"Schlummern", "Schmusen", "Dinner" und "Lesen" einzubauen, wenn die 
Liebste keinen Bock hat, auf dem Smartphone mit einem fisseligen 
Schieberegler herumzuhantieren. WAF matters! ;-)

Außerdem wäre ein "<form method=''>" ja leider mit einem 
Usabilityproblem behaftet: wenn der Schieberegler bewegt worden ist, 
täte sich erstmal gar nichts, bevor der Anwender nicht auf "<input 
type='submit'>" oder Ähnliches geklickt hätte. Finde ich nicht besonders 
elegant, ehrlich gesagt...

Wir können jetzt lange streiten, ob AJAX schon Server-to-Server ist und 
ob ein Webclient mit aktiven Inhalten in diesem Szenario als Server 
gilt.