Tach!
Nun, ob PUT oder POST, irgendwie ist das sowieso in sich widersprüchlich: Wie kann man eine Ressource requesten die es gar nicht gibt!?
Natürlich kann man Dinge erfragen, die es nicht gibt und die dann in dem Moment individuell angefertig werden. Das macht doch (d)ein CMS auch nicht anders, solange es nicht fertige Seiten aus einem Cache holt.
Doch, macht es. Beim meinem CMS wird ein neuer Inhalt an eine Ressource (Webservice) gesendet die es mit Sicherheit schon gibt. Anhand des gesendeten Content-Types weiß die Frameworkinstanz wie die Daten zu parsen sind, erhält body, title, descr usw., macht diese Daten persistent und schickt bei einer fehlerfreien Ausführung den Status 200 OK.
Also ich finde, man sollte sich bei Webservices nicht an den Requestmethoden festkrallen,
Für die Datenübertragung ist die Requestmethode völlig egal, die kannst Du auch Zitrone nennen. Entscheidend dafür, daß serverseitig Daten in STDIN anstehen ist nicht etwa POST oder PUT sondern die CGI-Ungebungsvariable Content-Length und das kann man in einschlägigen FRCs nachlesen.
Man kann sogar mit Request Methode GET einen Message Body senden und mit der neuen FetchAPI kann man den Namen der Requestmethode beliebig frei wählen.
Ich finde, man sollte bei einer REST-Schnittstelle genau das tun. REST ist ein Standard oder zumindest ein Quasi-Standard. Bei Abweichungen von diesem Standard kann man sonst keine REST-Tools out of the box verwenden.
Ich finde, wenn man schon ein Framework hat, daß man damit Requests für Webservices genauso behandelt wie jeden anderen Request auch. D.h. u.a. daß auf einer konfigurierten Webressource eine Instanz erstellt wird und so wie ich das hier sehen kann, passiert das auch in node.js wo man in der zur Ressource gehörigen Methode je eine Request- und eine Responseinstanz bekommt. Das ist in meinem FW ganz genauso nur halt anders umgesetzt.
Schönen Sonntag.