API Design - Denkfehler bei Parameterabfrage

[Synatex]

Hi,

bin momentan an einem kleinen Framework dran welches Leuten die Möglichkeit bietet ziemlich einfache REST API's zu bauen und wo man sich keine Gedanken über die Header, eventuelle Fehlermeldungen, das Format o.Ä. machen muss.

Bin nun nach dem Grundaufbau an nen Punkt angelangt wo ich nur bedingt weiter komme:

Als Beispiel nehmen wir die api 'user' und wollen einen finden. D.h. wir schicken ganz normal einen GET Request an die API. Per Slash ( / ) können weitere Parameter wie Suche nach ID, Namen, etc drangehangen werden. Gehen für nun mal von folgender URL aus:

PHP Code:

http://meine-api.de/user/name/Testuser/ 


Der Request-String wäre in diesem Fall:

PHP Code:

/user/name/Testuser 


Theoretisch alles klar. Die API ist vordefiniert und könnte theoretisch auch Slashes enthalten. Die Parameter sind jedoch nicht vordefiniert, haben keine bestimmte vorgeschriebene Länge und sind anderweitig auch nicht identifizierbar ausser durch die Trennung von dem Slash. Aber was ist nun, wenn im Nutzername auch Slashes vorkommen dürfen? (Was gar nicht so abwägig ist, besonders im Bereich VPN- und Tunneling). Dann würde sich das ganze so ergeben:

PHP Code:

/user/name/Test/user 


Dann hätten wir das Problem das es nun folgenden Aufbau ergeben würde:

PHP Code:

API: user
Action: GET
Params:
name => Test
user => 0 


Was natürlich nicht dem entspricht was wir haben wollen. Nun war meine Idee das ganze über nen Regex zu prüfen obwohl ich hier auch wieder gegen die Wand laufe da die Parameter wie gesagt nicht genau identifizierbar sind.

Hat da einer ne Idee wie man das lösen könnte?

[tolio]

einfach klassische uri queries nutzen?
Uniform Resource Identifier ? Wikipedia
Query String ? Wikipedia

[Synatex]

Das sind ja die 'normalen' Querys, hier ging es in dem Fall ja explizit darum dass das ganze über einen String übergeben wird eben mit dem Slash als Trennzeichen.

[Whoknowsit]

Einzige Möglichkeit besteht darin, die Übergabe von Usernamen Urlencoded zu erzwingen. Anders geht das nämlich nicht bzw. ist sehr fehleranfällig.

Ergo:

Andererseits ginge das schon, wenn die Parameter immer /user/name/ wären. Dann müsstest du aber mit dem dahinterliegenden Code rausrücken.

[iMarkt]

mod_rewrite

api.com/user/name/lala/lulu
wird zu
api.com/?param1=user&param2=name&param3=lala&param4=lulu

bzw. mein Tipp:
api.com/user$name/alter$23/legit$hax (i.ein einzigartiger String/Zeichen)
dann wieder umwandeln via mod_rewrite
dann splitten und nach Bedarf weiter verwenden

oooder bezüglich der Zeichenprobleme:
verschlüssel den Text für die API
api.com/user/awdl3wr8esiggxk/alter/adwadkg3255
und decodiere ihn im Nachinein.

Ps: ich weiß immer noch nicht, was du genau machen willst / wie du die Daten weiter verwenden willst, gibt schließlich sicher weiter mehr als 30 Lösungen

[Mashkin]

Ich denke du solltest deinem API-Router "beibringen", welcher Endpunkt welche Parameter unterstützt.
Mehrere Parameter als "/key1/value1/key2/value2" zu übergeben halte ich für

1. schwierig, weil dann genau dein Problem dabei herauskommt
2. unnötig, da du ja ein "Objekt" meistens sowieso nur mit einem Parameter identifizierst.
   Zum Beispiel macht es ja relativ wenig Sinn, einen User über zwei Parameter zu identifizieren:
   "/api/user/id/482/name/DerNameOderSo"
   Das ist ein schlechtes Design wie ich finde, erschwert auch z.B. das Caching (die selbe Ressource ist mit verschiedenen Parameterreihenfolgen erreichbar).

Wenn du z.B. eine Suche in die API integrieren willst und dafür mehrere Suchparameter ermöglichen möchtest, solltest du das vllt. doch mit klassischen Query-Strings realisieren oder auf POST-Anfragen ausweichen.


Um bei der POST-Variante den HTTP-Verben gerecht zu werden, könntest du einen Suchvorgang als Objekt betrachten, dass erst per POST hinzugefügt und dann per GET abgerufen wird.
So funktioniert z.B. auch die epvp-Suche (der POST-Request resultiert in einer Weiterleitung zum Suchergebnis, identifiziert durch eine ID).

[Synatex]

Whoknowsit hatte mir die Frage schon beantwortet. Trotzdem danke.

Um bei der POST-Variante den HTTP-Verben gerecht zu werden, könntest du einen Suchvorgang als Objekt betrachten, dass erst per POST hinzugefügt und dann per GET abgerufen wird.

Sorry, aber ich versteh genau in diesem Punkt momentan gar nichts. Hatte weder was mit der Fragestellung zutun noch ist das in irgendeiner Weise nen Problem, da ich POST Daten generell anders empfange als die die per GET kommen.

#closereq, bevor hier noch mehr kommt >.>

[MrSm!th]

Ohhh nein, andere Leute schlagen dir Verbesserungen vor, steinigt sie!
Es gibt zwar prinzipiell keinen Anspruch darauf, dass der Thread dann zu ist, wenn du es so willst, aber da weitere Vorschläge recht wenig Sinn machen, wenn du diese nicht lesen willst, hat ein Fortbestehen Thread natürlich ebenso wenig Sinn.
Heute mal ausführlicher begründet.

#closed