Forum: PC-Programmierung Frage zu HTTP Post response


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Thomas (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von bluppdidupp (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Das hört sich an als würdest du den POST-Request nicht per AJAX sondern 
per form-submit oder ähnlich senden?

von leo (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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

von Hmmm (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Thomas (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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:
if(window.XMLHttpRequest)
{
  r = new XMLHttpRequest();
}
else if(window.ActiveXObject)
{
  try
  {
    r = new ActiveXObject('Msxml2.XMLHTTP');
  }
  catch(e1)
  {
    try
    {
      r = new ActiveXObject('Microsoft.XMLHTTP');
    }
    catch(e2)
    {
      document.getElementById('status').innerHTML = 'Could not open handler.';    
    }
  }    
}

slide.onchange = function() {  
  if(r != null)
  {
    var brgth_value = document.getElementById('brgth_slide').value;
  
    r.open('POST', '192.168.0.18', true);    r.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');
    r.send('brgth='+brgth_value);
 
    document.getElementById('status').innerHTML = 'Request gesendet.';
  }
};

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

von Sascha W. (sascha-w)


Bewertung
1 lesenswert
nicht lesenswert
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

von Aalpaule (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Logge mal mit was der Arduino genau antwortet, dann kann man 
weiterhelfen.

von Εrnst B. (ernst)


Bewertung
0 lesenswert
nicht lesenswert
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

von sid (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ε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

von Sascha W. (sascha-w)


Bewertung
0 lesenswert
nicht lesenswert
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

von Thomas (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von sid (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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

von Marco H. (damarco)


Bewertung
-1 lesenswert
nicht lesenswert
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
von sid (Gast)


Bewertung
-3 lesenswert
nicht lesenswert
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

von Krapfenzüchter (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Εrnst B. (ernst)


Bewertung
0 lesenswert
nicht lesenswert
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.

von sid (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
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

von Marco H. (damarco)


Bewertung
1 lesenswert
nicht lesenswert
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.....

von Εrnst B. (ernst)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Jimmy (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Ε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.

von Jimmy (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Achso, mein Schrieb bezieht sich auf AJAX.

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
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/

von sid (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von S. R. (svenska)


Bewertung
2 lesenswert
nicht lesenswert
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.

von Sascha W. (sascha-w)


Bewertung
-1 lesenswert
nicht lesenswert
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

von Sheeva P. (sheevaplug)


Bewertung
-1 lesenswert
nicht lesenswert
sid schrieb:
>> POST is NOT idempotent.

Pardon, aber welchen Teil davon hast Du nicht verstanden?

von Sheeva P. (sheevaplug)


Bewertung
-1 lesenswert
nicht lesenswert
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? ;-)

von Εrnst B. (ernst)


Bewertung
-2 lesenswert
nicht lesenswert
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?

von sid (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
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. ;-)

von sid (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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

von Εrnst B. (ernst)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
Ε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

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
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?

von sid (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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

von Εrnst B. (ernst)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Berufsberater (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Sheeva P. (sheevaplug)


Bewertung
-2 lesenswert
nicht lesenswert
Ε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...

von Sheeva P. (sheevaplug)


Bewertung
-1 lesenswert
nicht lesenswert
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
von Εrnst B. (ernst)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
Ε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.
$.ajax({
  url: '/set/bulb1/',
  type: 'PUT',
  data: "hue=15",
  success: function(data) {
    alert('Hue was set.');
  },
  error: function(data) {
    alert('ERROR: Could not set Hue. Please see error logs.');
  }
});

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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.