PFZ.nl - PHP Community: [ZF] Zend Rest Route en Apikey - Frameworks - Forum - PFZ.nl - PHP Community

Beste leden,

Ik ben bezig met een API voor ons administratie systeem. Ons systeem is gebouwd door middel van Zend Framework, hier zit een REST zerver optie is. Deze gebruiken wij om de API op te bouwen.

Nu werken wij op basis van een API key, deze API key wordt afhankelijk van de actie per POST of per GET meegestuurd.
Bij voorbaat zou ik bij alle acties (GET, POST, PUT en DELETE) de apikey altijd via de URL mee willen geven, maar Zend laat dit niet toe, zo gauw die meer dan 0 params in de URL ziet maakt die van een POST actie een PUT actie.

De rest van de data verzend ik bij een POST wel netjes via een echte POST array, maar betreft de APIkey zou ik bij voorkeur toch één lijn bij alle elementen willen hebben.

Nu heb ik de code gevonden waar de REST actie bepaald wordt, dit is het volgende stukje:

1 2 3 4 5 6 7 8 9 10 11 12

switch( $values[$this->_actionKey] ){ case 'post': if ($pathElementCount > 0) { $values[$this->_actionKey] = 'put'; } else { $values[$this->_actionKey] = 'post'; } break; case 'put': $values[$this->_actionKey] = 'put'; break; }

Dit kan ik simpel oplossen door $pathElementCount > 0 te wijzigen in $pathElementCount > 1, maar ik wil logischerwijs niet rotzooien in de CORE van Zend, iemand tips om dit te omzeilen via een plugin bijvoorbeeld? Hoe zou je dit dan aan moeten pakken?

Erwin

Vergeet het meesturen van de APIkey in de URL, dat is juist niet RESTfull ;)

Kijk eens naar basic auth of bijvoorbeeld Digest auth voor authenticatie.

Eventueel zou je ook met custom headers oid kunnen gaan werken. Maar er zijn genoeg gestandaardiseerde methodieken voor authenticatie.

Quote

Hoe zou je dit dan aan moeten pakken?

Niet. PUT = edit, POST = add, Params = "where clause"

Als jij iets wilt toevoegen dan zit alle data dus in de POST, de response geeft je dan een nieuwe resource identifier terug die je vervolgens weer in je "where" (params) kunt gebruiken bij een PUT (edit) actie.

De "API" key hoort sowieso niet thuis in je params (zie hierboven), denk eerder dingen zoals een "resource id" die met PUT gewijzigd moet worden, filters voor overzichten die met GET opgevraagd worden, etc.