REST est-il adapté aux grands modèles 3NF ?

Question

Il existe de nombreux exemples d'utilisation de REST avec des modèles de données simples. Par exemple, un client avec 5 propriétés et une collection de commandes avec 6 propriétés. Cependant, j'ai du mal à visualiser l'utilisation de REST avec un modèle plus complexe, comme on peut en trouver dans les marchés publics, les finances, la gestion des dossiers médicaux, etc. Existe-t-il des exemples d'utilisation de REST comme API principale dans un grand environnement LOB ?

Peut-être que j'en demande trop à l'approche REST ?

Answer 1

Je suis en train de construire une interface REST qui compte actuellement plus de 250 ressources. Lorsque j'aurai terminé, j'espère en avoir plus de 1000. Il s'agit d'une application ERP qui couvre la comptabilité, les stocks, les ventes, le coût de la main-d'œuvre, l'ingénierie, etc.

La taille ou la complexité d'une ressource unique n'est pas directement liée à REST mais plutôt aux types de médias. J'ai choisi de définir mon propre type de média car je construis également le client et l'interface n'est pas destinée à la consommation publique. Choisir le meilleur type de média pour votre situation est probablement l'une des parties les plus difficiles de la conception d'une interface REST.

Malheureusement, la plupart des gens semblent faire l'impasse sur la décision concernant le type de média et choisissent le format générique application/json ou application/xml, puis utilisent le javascript téléchargé dans le navigateur pour interpréter le format[1]. Cela fonctionne tant que le seul client dont vous disposez est un navigateur et que vous ne voulez pas que quelqu'un d'autre réutilise votre interface. Pour moi, cela semble aller à l'encontre de l'un des principaux objectifs de REST, à savoir la réutilisation sereine due à un couplage lâche et à des formats standardisés.

Pour mieux expliquer ce que j'entends par là, considérons le cas où vous fournissez une application/json ou une application/xml à une application cliente. Dès que l'application cliente accède à ce format générique et en extrait un élément de données spécifique, vous créez un couplage caché entre le client et le serveur. Si, au contraire, vous utilisez le format de média "application/vnd.mycompany.myformat+xml", vous définissez explicitement un contrat avec le client. Cela présente un avantage considérable lorsque vous apportez des modifications au format et que vous avez la possibilité de créer "application/vnd.mycompany.myformatV2+xml".

Les gens perçoivent REST comme une interface vaguement spécifiée, mais en réalité, ce n'est pas le cas. Une interface REST doit être très explicite quant aux types de médias précis qu'elle renvoie et s'attend à recevoir. Les types de médias constituent le contrat. Si vous recevez application/xml et que vous utilisez du code client pour extraire /Customer/Name, vous rompez le contrat.

Les applications Web qui utilisent le javascript téléchargé peuvent consommer "application/xml" parce que les détails du contrat ne sont pas compilés dans le client. Cependant, le comportement du client est extrêmement limité à ce que le javascript a été préprogrammé pour faire. Malheureusement, la majorité des interfaces publiques RESTful ignorent cette contrainte et les gens construisent des clients qui sont étroitement liés à un contrat non spécifié. C'est pourquoi, lorsque Twitter change son format, de nombreux clients se cassent.

Answer 2

REST est un style architectural, pas une représentation des données. Aujourd'hui, les données sont généralement représentées en XML ou en JSON, qui ont fait l'objet de nombreux tests et peuvent facilement prendre en charge les grands modèles complexes auxquels vous faites référence.

Dans sa forme la plus élémentaire, REST consiste simplement à utiliser les verbes HTTP pour contrôler une "ressource". La représentation de cette ressource peut être aussi simple ou aussi complexe que vous le souhaitez. Les opérations CRUD et de liste sont les plus directes. Des API supplémentaires, plus complexes, peuvent également être générées facilement dans ce contexte.

Answer 3

REST convient tant qu'il existe un chemin descriptif raisonnable pour décrire les données que vous souhaitez atteindre.

REST ne donne pas l'impression d'être RESTful lorsque ce que vous essayez d'accomplir est de publier une API, MAIS, je voudrais noter que les API qui ont été développées en utilisant la philosophie REST ont été très réussies.

D'après votre description, vous travaillez avec des données, qui devraient très bien adhérer à REST, quelle que soit la complexité de la structure. REST n'interdit pas la publication de schémas, vous pouvez donc également y réfléchir.