Hallo zusammen, ich habe aktuell ein Projekt, bei welchem ich auf einfachste Art und Weise Daten von einem Browser zu einem Server schicken möchte. Der Server ist in dem Fall ein ESP als AccesPoint, welcher auf Port 80 entsprechend auf GET Anfragen mit HTML Code antwortet, welcher dann im Browser des Client dargestellt wird. Das funktioniert auch schon alles super. 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... Meine Frage ist nun die folgende: Wie muss ich die Response vom ESP zum Browser gestalten, damit dieser seinen HTML Code behält und nicht erneut auf HTML Code wartet. 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. Den HTML Code erneut zu übermitteln funktioniert zwar, allerdings ist dann der Schieberegler ja wieder auf dem Default Wert, was die Bedienung sehr unschön macht. Ist es überhaupt möglich dass der Browser nur einen POST Request schickt und seine Sources dabei behält? Oder muss ich zwangsläufig auf dem ESP den Wert des Reglers in den HTML-Code pipen und dann die Website mit dem neuen Reglerwert zurücksenden? Gern kann ich konkreten Code bereitstellen, aber hier geht es zunächst einmal um das Verständnis und das Grundprinzip. Vielen Dank schon einmal! Viele Grüße Thomas
Das hört sich an als würdest du den POST-Request nicht per AJAX sondern per form-submit oder ähnlich senden?
Thomas schrieb: > Dieser Wert wird dann mittels Post > zum ESP geschickt. Das hat man im letzten Jahrtausend so gmacht. Ajax ist auch steinalt. Schau dir mal "Web Socket" an. https://github.com/Links2004/arduinoWebSockets leo
Thomas schrieb: > Ist es überhaupt möglich dass der Browser nur einen POST Request schickt > und seine Sources dabei behält? Du kannst dem <form> einen Parameter "target" mitgeben. An der passenden Stelle ein <iframe> plazieren, und das Script gibt dann nur etwas wie "Änderung erfolgreich" (in eine minimale HTML-Seite verpackt) zurück, was an dieser Stelle angezeigt wird. leo schrieb: > Das hat man im letzten Jahrtausend so gmacht. Ajax ist auch steinalt. > Schau dir mal "Web Socket" an. Völliger Overkill und zudem auf der Serverseite eklig zu implementieren.
bluppdidupp schrieb: > Das hört sich an als würdest du den POST-Request nicht per AJAX sondern > per form-submit oder ähnlich senden? Hallo, vielen Dank für die schnellen Antworten! Nein eigentlich mache ich das mittels JS:
1 | if(window.XMLHttpRequest) |
2 | {
|
3 | r = new XMLHttpRequest(); |
4 | } |
5 | else if(window.ActiveXObject) |
6 | {
|
7 | try |
8 | {
|
9 | r = new ActiveXObject('Msxml2.XMLHTTP');
|
10 | } |
11 | catch(e1) |
12 | {
|
13 | try |
14 | {
|
15 | r = new ActiveXObject('Microsoft.XMLHTTP');
|
16 | } |
17 | catch(e2) |
18 | {
|
19 | document.getElementById('status').innerHTML = 'Could not open handler.';
|
20 | } |
21 | } |
22 | } |
23 | |
24 | slide.onchange = function() {
|
25 | if(r != null) |
26 | {
|
27 | var brgth_value = document.getElementById('brgth_slide').value;
|
28 | |
29 | r.open('POST', '192.168.0.18', true); r.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');
|
30 | r.send('brgth='+brgth_value);
|
31 | |
32 | document.getElementById('status').innerHTML = 'Request gesendet.';
|
33 | } |
34 | }; |
Ist eine Post Request aus einem Form anders als die hier genutzte Variante? Das ist interessant! In wie fern ist das so? Ich wollte nämlich noch Buttons hinzufügen und diese dann als forms laufen lassen,.. das lasse ich dann wohl lieber. Bzgl. des Websockets: vielen Dank für den Input! Ich schaus mir direkt mal an! Ich habe mich nur auf das HTML beschränkt, weil ich speichertechnisch eingeschränkt bin und darüber hinaus auch weit weg von einem erfahrenen Webdeveloper.. Vielen Dank soweit schonmal für eure Antworten! Grüße Thomas
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
Logge mal mit was der Arduino genau antwortet, dann kann man weiterhelfen.
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
Εrnst B. schrieb: > Antworte mit "204 No Content". das ist in der Tat die einfachste Lösung (nicht aber zwingend die einzig richtige;)) Ich für meinen Teil halte es für nicht unsinnig zB die schieberegler und button-stellung (für radio und checkboxes oder active/disabled etc...) via AJAX zurückzusenden.. ich mach das gewöhnlcihüber ne JSOn response, winfach weil sie recht bequem ist. websockets halte ich für Deine Anwendung für überflüssig, sie sind quasi die permanent verbindung zwischen zwei nodes, was eben permenent auch minimalen Traffic erfordert. und eben einen handler der verlorene(ausser Reichweite) nodes wieder einfängt wenn sie wieder auftauchen, alles kein grosses Ding, aber eben nicht wirklich nötg. Wenn eine Anfrage via ajax gestellt wird (nur wenn DU was änderst) ist der Server ja vermutlich in Reichweite und man spart sich den Krempel... aber auch das ist vermutlich Geschmacksache. Und nur weil es Ajax schon seit XY Jahren gibt, heisst das nciht dass es veraltet ist. Ich mein.. Mobiltelefonie gibt's auch seit den 1950ern und selbst wenn wir nur die breite Masse betrachten auch schon seit weit mehr als 30 Jahren Aber nimm den "alles muss neu"-Affen mal das Handy weg, dann ist das Geschrei aber gross ;) Solange was gut funktioniert (und das tut ajax ja) kann man es auch ruhig verwenden. Der IMHO wichtige teil ist, dass du den response handler im Javascript unter Kontrolle bekommst, denn solange das Javascript meint es müsse eine Seite neu laden, macht es das auch. Der ist es was das synchrone (page reload) zum asynchronen (page rewrite) script macht. eine grobe Einführung findest Du hier: https://www.w3schools.com/js/js_ajax_intro.asp inkl einiger kurzer Beispiele https://www.w3schools.com/js/tryit.asp?filename=tryjs_ajax_first Ich denke daran wirst Du Dich gut entlanghangeln können 'sid
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
Hallo zusammen, ich zitiere mich jetzt mal nicht durch weil einfach alle Antworten sehr aufschlussreich sind! Vielen vielen Dank für die schnelle und kompetente Hilfe von euch! Ich werde heut Nachmittag mal die 204 ausprobieren, das wäre in der Tat das einfachste. 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. Nochmals vielen Dank auch für die Links und die vielen Möglichkeiten. Ich hab dazu echt kaum was sinnvolles gefunden (vermutlich auch, weil ich nicht die richtigen Tags zur Suche verwendet habe). Bleibt gesund! Viele Grüße Thomas
Sascha W. schrieb: > 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. Ich würde dem widersprechen! websockets sind niemals für unidirektionale Anweisung die keinerlei unvorhergesehene Rückmeldung an den Steller erfordert die "richtige" Wahl. Rückmeldung nach Anweisung ist ein post-response websockets braucht es nur wenn man nicht weiss wann der Server ne Meldung schickt. und für vorliegenden(und ähnlichen) Fall auch immer overkill (und damit die falsche Wahl ausgehend vom KISS Konzept ;)) Websockets sind für bidirektionale Kommunikationsanwendungen Webchats und Co, wenn man nicht weiss wann sein Gegenüber auf ne Nachricht reagiert oder für Zeitkritische Steuerungsanweisung "Die CNC Fräse knallt grade wie doof gegen den Endschalter.. Tu' Was Heinz, SCHNELL!" n doofen LED Streifen gehört da sicherlich nicht zu! 'sid
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....
:
Bearbeitet durch User
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 ;) POST und GET unterscheiden sich in der Art der Datenübermittlung vom Client zum Server.. und die Statusmeldung hat damit noch gaaarnix zu tun (ich kann auf einen korrekten request jeden response header schicken den ich will 102, 200, 201, 204, 300, 303, 305, 403, 404, 504... JEDEN! die zwei stehen in keinem Zusammenhang den ich nicht beeinflussen könnte) Marco H. schrieb: > 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. LOOL, wenn man nicht weiss was man tut (und wenig davon versteht) mag das stimmen. wenn man weiss was man tut und nicht nur Codezeilen zusammenkopiert kann man dutzende Requests auch parallel an den Server schicken und via Ajax verarbeiten. 'sid
Das hier ist die Referenz https://www.rfc-editor.org/info/rfc7230 Das lest ihr alle mal brav, dann könnt ihr euch wieder unterhalten.
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.
Sagt eins, ihr habt doch ne Meise.. "Server [ESP] steuert Lampe"; nicht "Lampe ist Server"! Das wär ja sensationell dämlich... Der Server teilt der Lampe mit welche Farbe/Helligkeit/Status sie gefälligst zu haben hat (Mintgrün, ~30%, AN) Also reicht ein GET Request! (oder weil's bequeemer ist der URI keine parameter anzuhängen ein POST Request) postdata set: c=#22F7E0, b=30, oo=1 Der Server teilt die Werte der Lampe mit und bestätigt den Empfang. DONE! bei nicht parametisiertem Aufruf belibt der Status gespeichert und wird zurückgegeben Hätte man einen Zentralserver (sei's n Raspi oder n 'richtiger') und würde sich der ESP an dem anmelden sobald er 'erneut' von Strom versorgt würde und hätte sich seine Aufgabe geändert (sagen wir er steuert jett die Garagenlüftung nichtmehr die Lampe) oder der Hauptserver hätte vergessen was des ESP Aufgabe ist (ja empty node konzepte können [sehr selten] Sinn machen) Dann kommt PUT ins Spiel (Hey Server, I'm here, let me know if someone requires XY or Z which I can provide) Aber da der ESP selbst der Server ist ist das doch hier vollkommen überflüssig. Gut ich halte auch n webserver auf dem ESP für nutzlos um ne Lampe zu schalten.. bei mir läuft aber in der Tat permanent ein Server, der könnte dann nem ESP Clientnode mitteilen was zu tun wäre aber das ist ja hier nun ebenso nicht der Fall wie die Notwendigkeit eines PUT requests. Prinzipiell reicht in der Tat ein no-reply poll, der aber immer schwierig zu debuggen ist wenn man nicht weiss wonach man suchen soll. Ein simples GET oder IMHO besser POST löst jede 'mach XYZ' Anfrage zweifelsfrei (und ist debugging freundlich). mit oder auf Wunsch ohne Statusrückmeldung... ich wiederhole mich... Und wenn jetzt jeder nochmal auf's Thema schielt dann weiss jeder auch warum HTTP POST REQUEST für "HTTP POST *response*" vermutlich auch die zielführendere Antwort ist ;) shalömmchen 'sid
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.
Εrnst B. schrieb: > 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. > GET Requests ohne custom headers ziehen keinen zusätzlichen Preflight request im Cross-Domain-Fall nach sich, bei dem der Server erlaubende CORS header senden muesste. Daher kann man mit GET für Drittpartei-Domains modifizierende Aktionen machen, die unter dem Radar der Browsersicherheit bleiben. Die Trackingnetzwerke suchen nur technische Lösungen um ihr Business weiter treiben zu können und nutzen diese Umgehungen für sich aus. Selber für seine Serverapplikation GET statt POST/PUT/DELETE zu verwenden bedeutet, dass man die Sicherheitsfeatures wie CSRF Tokens absichtlich untergräbt. Da sich die Entwicklung von Sicherheitsfeatures an der Praxis orientiert, ist man auch gut beraten sich an gängigen Standards zu orientieren. Bastellösungen vielleicht mal ausgenommen. Es gibt übrigens auch GET mit Body. Manche Proxies unterstützen das aber nicht, von REST clients ganz zu schweigen.
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/
Sheeva P. schrieb: > räusperhüstel Entschuldige bitte, aber Marco hat vollkommen Recht. PUT > existiert und ist für genau die Dinge vorgesehen, die Marco beschreibt. in dem Post (oh verwirrung) "Beitrag" den ich da zitierte beschrieb er garnix ;) Und für nen "do this" Befehl der vom webclient zum webServer soll, der dann im Gegenzug nem Node erzählt was der Client will ist PUT falsch. ich zitiere mal deinen Link: > Use PUT when you want to modify a singular resource > which is already a part of resources collection. Ne, will ich nicht Okay zitieren wir mal die RFC2616 https://www.ietf.org/rfc/rfc2616.txt > The GET method means retrieve whatever information > (in the form of an entity) is identified by the Request-URI. hmm okay klingt langweilig... aber schon der nächste Satz > If the Request-URI refers to a data-producing process, > it is the produced data which shall be returned Ahaaa ich kann also mit Get daten "produzieren" also zum Beispiel eine Statusänderung induzieren und den darauffolgenden Status zurückgeben. das ist doch dufte... Und weil das dufte ist, nahm ich an Marco meinte GET (weil es nutzt) > The actual function performed by the POST method is determined by the > server and is usually dependent on the Request-URI. Ach schau an, was POST tut entscheide ich indem ich den Server entsprechend aufsetze... und weiter: > POST is designed to allow a uniform method to cover the following functions: > - Providing a block of data, > such as the result of submitting a form, > to a data-handling process; um Daten zu versenden die dann von einem Prozess verarbeitet werden sollen interessant.. Also zB einen Intensitätscode an einen PWM zu schicken ?? weiter auf seite 54 derselben rfc2616 > The PUT method requests that the enclosed entity be stored under the > supplied Request-URI Ne nochmal.. wir wollen GARNIX speichern oder erstellen! Wir wollen existierendem sagen was zu tun ist, und ggf darüber ne Rückmeldung haben ("hat geklappt", "hat nicht geklappt", "das Lichtband kann keinen Kaffee machen") Ich wiederhole mich.. PUT ist schwachsinn in dieser Kommunikation! Nochmal: "ESP" Webserver ist da um ne Lampe zu steuern (direkt kabelgundenen 'ressource') die 'Fähigkeiten' der Lampe sind fix definiert (An/Aus, Heller/dunkler, Farbe) das ist die Konfiguration von der ich ausgehe... der Benutzer will nun Farbe, Helligkeit oder Zustand ändern, dazu braucht NICHTS verändert und NICHTS angelegt zu werden. da reicht eine parametrisierte Aufgabenstellung und im Sinne der Vollständigkeit (weil man ja nicht sehen kann ob die Lampe jetzt an oder aus ist, heller oder dunkler oder rot statt grün #kopfschüttel) noch die Rückmeldung ob das Erfolg hatte. ---------------------------------------------- Hätte man allerdings eine ANDERE Aufteilung, nämlich einen Server der ALLES verwaltet und einen externen Node der sich nur um die Lampe kümmert und zu allem Überfluss per WiFi verbunden wird DANN Meldet sich jener NODE am Server mit dem PUT Request an um seine Ressource anzulegen, oder sie eventuell zu modifizieren (neue IP?, Licht geht nichtmehr in der Farbe zu ändern oder oder) Das hat aber mit der Clientapplikation auf dem Handy/Tablett des Benutzers NIX zu tun!! (und ja das geht auch mit POST.. übrigens auch ohne hunderttausend neue Ressourcen anzulegen) (wieder Dein Link zitiert) > POST is NOT idempotent. So if you retry the request N times, you will > end up having N resources with N different URIs created on server. Ist also nur dann richtig, wenn der Administrator ein kompletter Vollidiot ist und sich nur in dem Zusammenkopieren bestehender Skripte auskennt (und das auch nur mässig) Hat man unter Kontrolle was man tut (zum Beispiel weil man seit 1998 Webserver programmiert und durchaus in der Lage ist sich mal ne Nummer zu merken) kann man das leicht verhindern. 'sid
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
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?
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? Ja dazu muss man mehr können als Beispiele aus dem internet zusammenzukopieren stimmt.. aber da man das wie gesagt nichtmal braucht, kommt man wohl auch mit nur mässigem Wissen aus, denn Εrnst B. schrieb: > unabhängig von POST/PUT/PATCH/GET/Websocket: Wo will man in einer > Lampen-Steuerung Idempotency? korrekt, will man nicht, braucht man nicht! sag ich doch. 'sid
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: > sid schrieb: >> Was hast Du daran nicht verstanden? > > Danke für den Hinweis, aber... ich hab' das schon sehr gut verstanden. Ne ich fürchte immernoch nicht. 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. Soweit alles prima AAABer das hat mit dem PUT BLÖDSINN nichts zu tun, denn PUT ist hier der falsche weg.. braucht es zu NIX, zu garnix, idempotency ist so unnötig wie ein akustisches Signal an der Lampe die den Farbton per moduliertem Rechtecksignal zurückgibt. klar kann man das so lösen... macht aber keinen Sinn und ist 100%ig unnötig. 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. (die Anfrage wird nach Ausführung vollständig verworfen.. und fertig) 'sid
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?
Meine Güte laberst Du eine gequirlte Kacke, ist ja sagenhaft ist doch Hupe ob zwei Zustände oder 6*10^80 es bleibt ja dieselbe Lampe! Du bekommst ja auch kein neues Kennzeichen ans Auto weil Du den Sender im Radio wechselst. 'sid
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.
REST ist im Prinzip nur eine Empfehlung/Konvention wie man gewisse Dinge einheitlich umsetzt und dafür HTTP missbraucht. 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. Er nutzt HTTP für seinen Zweck, wie er das dann einsetzt interessiert keinen solange er selbr weiss was er tut und das nicht durch Dritte genutzt werden soll, dann gibts evt. Probleme. Leute der will ne Lampe ein und ausschalten, mehr nicht. Was hier für ein akademischer Schwachsinn draus gemacht wird ist ja nicht zu fassen. Ich würde es mit GET machen, para=wert ranpappen, fertig. Einfach und simpel, den Response kann man dann auch noch auswerten wenn man will.
Ε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.
:
Bearbeitet durch User
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.