PUT, PATCH - Update modelu i upload pliku

Question

Do rzeczy:

REST webservice wraz z PSR-7.

Próbuje zrobić aktualizacje wpisu/użytkownika/cokolwiek innego ze zmianą dołączonego do niego pliku (np. awatara). Według zasad powinno to być zrobione za pomocą requesta metodą PUT albo PATCH.
Kłopot w tym, że php nie parsuje php://input do globalniej $_FILES, tak jak jest to w przypadku POST. Jeśli nie ma $_FILES, to UploadedFile z requesta jest pusty.

Z tego, co udało mi się wygooglować/ktoś mi pomogł, to mogę wysyłać POST z argumentem _method i po middleware zmieniać requesta przez metode withMethod. Tak robi laravel. Jest to słabe o tyle, że client i tak musi wykonać requesta przez POST, a nie PUT/PATCH.

Inną opcją jest parsowanie body requesta, ale trochę jest z tym kombinowania, więc podchodzi to pod KISS. Chyba że są jakieś narzędzia do tego.

Inną opcją jest po prostu rzucanie update przez POST, ale wtedy nie mamy RESTfula.

Wasze propozycje?

Comments

http://php.net/manual/en/features.file-upload.put-method.php

http://stackoverflow.com/a/27944729

---

Widziałem, ale: 

Inną opcją jest parsowanie body requesta, ale trochę jest z tym kombinowania

 =/

---

To jest dużo kombinowania? :D Serio jak dla mnie to jest to lepsze niż jakiś middleware, który to wygląda w tym przypadku jak łatanie dziury w drodze plombą od dentysty.

---

A gdzie indziej niby miałbym to wstawić niż w middleware?

Przepakować kontroler? Czy może do modelu przed walidacją?

---

Chodziło mi o ten konkretny middleware z _method i withMethod. Sorry, źle się wyraziłem.

Answer 1

Inną opcją jest po prostu rzucanie update przez POST, ale wtedy nie mamy RESTfula.

A czy Twój RESTful jest zgodny w HATEOAS i jest samodokumentujący? Jeśli nie - to zrób najprościej jak się da w tym wypadku. Jeśli mówisz o RESTful to jest maasa rzeczy o których w ogóle ludziom się nie śniło jeszcze.  

Comments

A czy Twój RESTful jest zgodny w HATEOAS i jest samodokumentujący?

Jak jeszcze HATEOAS przełknę, tak mrzonka o samodokumentującym się REST API mnie zawsze bawi na tyle, że zaliczam ROTFL-a. Nie ma czegoś takiego jak "samodokumentujące się REST API". No nie ma. 

---

I raczej nie będzie - więc nie powiemy raczej o tym, że nasze API jest RESTful, tylko zbliżone do niego.

Aczkolwiek próby są: https://github.com/justintv/Twitch-API#self-describing-api

:D

---

Skoro dana rzecz nie istnieje i nie da się jej stworzyć, to po co tworzyć ich definicje i wierzyć w nie? To mnie drażni w tej rozdmuchanej nomenklaturze strasznie.

---

Einstein również stworzył matematyczny opis czarnej dziury, która to została potwierdzona lata po jego śmierci.

To normalna cecha towarzysząca rozwojowi. RBAC też został opisany a nigdzie nie został zrobiony na tyle dobry odpowiednik jego aby był godny większej uwagi. A idea świetna i dużo bardziej sprawdza się w rozbudowanych przykładach niż ACL.

Nie ma co się pieklić, kiedyś albo to zupełnie padnie, umrze śmiercią naturalną, albo rozwinie skrzydła i znajdzie sobie drogę do "normalności"

---

Einstein również stworzył matematyczny opis czarnej dziury, która to została potwierdzona lata po jego śmierci.

A od kiedy programowanie to wydumana nauka nad rzeczami, które i tak nigdy nam się nie przydadzą oprócz samego faktu pogłębienia przez nie wiedzy?

Programowanie ma rozwiązywać realne problemy. Nie rozwiązuje, to coś poszło nie tak. Tyle. 

Wymyślanie super zawiłych podstaw teoretycznych i modlenie się do nich nie oznacza rozwoju. To gonienie za własnym ogonem.

Answer 2

To tak btw:

Slim tak samo jak Laravel ma fallbacka w postaci dodatkowego parametru. Jak się doda do paramsów zmienną "_METHOD" (wielkość liter jest ważna), to zmienia request method.

Szkoda, że jak się wysyła patcha/puta, to trzeba samemu parsować dane, bo na php nie ma co polegać...