Comment concevoir une API REST avec des critères LIKE ?

Question

Je suis en train de concevoir une API REST et j'ai une entité pour les "personnes" :

GET http://localhost/api/people

Renvoie une liste de toutes les personnes présentes dans le système.

GET http://localhost/api/people/1

Retourne la personne avec l'id 1.

GET http://localhost/api/people?forename=john&surname=smith

Il renvoie toutes les personnes dont les noms et prénoms correspondent, mais j'ai une autre exigence. Quelle est la méthode la plus propre et la plus efficace pour permettre aux consommateurs de l'API de récupérer toutes les personnes dont le prénom commence par "jo", par exemple ?

J'ai vu certaines API faire cela comme :

GET http://localhost/api/people?forename=jo~&surname=smith

où le tilde signifie une correspondance "floue". D'un autre côté, j'ai vu qu'il était implémenté avec un critère totalement différent, par ex.

GET http://localhost/api/people?forename-startswith=jo&surname=smith

ce qui semble un peu lourd si l'on considère que je pourrais avoir -endswith, -contains, -soundslike (pour une sorte de correspondance soundex).

Quelqu'un peut-il suggérer, à partir de son expérience, ce qui fonctionne le mieux et également des exemples d'API REST bien conçues qui ont une fonctionnalité similaire.

Answer 1

À mon avis, il importe peu que vous ayez des correspondances floues ou que vous ayez -endswith -contains etc. Ce qui importe, c'est que votre API REST permette d'analyser facilement de tels paramètres afin que vous puissiez définir des fonctions permettant d'extraire des données de votre source de données (base de données, fichier xml, etc.) en conséquence.

Si vous utilisez PHP... d'après mon expérience, SlimFramework est une excellente solution légère et facile à mettre en œuvre.

Answer 2

Je vous recommande le Protocole OData qui fournit un Options de la chaîne de requête . Ce que vous avez fait est correct et suit les conventions REST.

Mais, le protocole OData décrit un $expand et même un paramètre $filter paramètre. Ce site $ Le préfixe indique "System Query Options" et la dernière vous intéressera car elle vous permet d'écrire l'URI suivant :

http://services.odata.org/Northwind/Northwind.svc/Customers?$filter=tolower(CompanyName) eq 'foobar' &select=FirstName,LastName&$orderby=Name desc

Il vous permet de passer des données de type SQL et peut être une alternative intéressante à ce que vous avez décrit (les deux solutions sont bonnes, c'est juste une question de goût).

Answer 3

À ma connaissance, aucun des éléments ci-dessus n'est tout à fait RESTful. Les deux reposent sur une connaissance préalable de la part du client sur la façon d'invoquer des requêtes (dans le premier cas, un modèle de requête et dans le second un DSL de requête). Dans le second exemple, en fait, l'API se réduit à une simple enveloppe autour du magasin de données. En tant que telle, l'API ne définit pas un domaine de serveur - elle est un fournisseur de données. Ceci est en contraste avec l contrainte client-serveur de REST.

Si vous avez besoin d'exposer un magasin de données complet avec toutes les capacités d'interrogation, vous feriez mieux de vous en tenir aux normes connues dont nous disposons. OData . OData a été vendu comme REST, mais de nombreux adeptes de REST ont des problèmes avec lui. Quoi qu'il en soit, en fin de compte, cela fonctionne et les discussions sur REST peuvent généralement conduire à une analyse-paralysie.

Si je faisais cela, je limiterais probablement l'API à un cas d'utilisation courant, donc quelque chose qui ressemble plus au deuxième cas sans définir un DSL de requête (d'où forenameStartsWith plutôt que forename-startswith).

Cela dit, si vous avez besoin d'effectuer des requêtes sur la base de nombreux champs et de diverses conditions, j'utiliserais OData.

Answer 4

Les deux exemples utilisent des paramètres de requête pour le filtrage. Je ne pense pas que le nom de ces paramètres de requête ou l'utilisation d'une syntaxe joker aient une importance.

Les deux approches sont tout aussi RESTFul.