larlet-fr-david/david/stream/2015/05/09/index.md

title: REST et complexité

> We believe there are a number of weakness in typical REST systems, ones that are particularly problematic in mobile applications:
>
> * Fetching complicated object graphs require multiple round trips between the client and server to render single views. For mobile applications operating in variable network conditions, these multiple roundtrips are highly undesirable.
> * Invariably fields and additional data are added to REST endpoints as the system requirements change. However, old clients also receive this additional data as well, because the data fetching specification is encoded on the server rather than the client. As result, these payloads tend to grow over time for all clients. When this becomes a problem for a system, one solution is to overlay a versioning system onto the REST endpoints. Versioning also complicates a server, and results in code duplication, spaghetti code, or a sophisticated, hand-rolled infrastructure to manage it. Another solution to limit over-fetching is to provide multiple views – such as “compact” vs “full” – of the same REST endpoint, however this coarse granularity often does not offer adequate flexibility.
> * REST endpoints are usually weakly-typed and lack machine-readable metadata. While there is much debate about the merits of strong- versus weak-typing in distributed systems, we believe in strong typing because of the correctness guarantees and tooling opportunities it provides. Developer deal with systems that lack this metadata by inspecting frequently out-of-date documentation and then writing code against the documentation.
> * Many of these attributes are linked to the fact that “REST is intended for long-lived network-based applications that span multiple organizations” [according to its inventor](http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven). This is not a requirement for APIs that serve a client app built within the same organization.
>
> Nearly all externally facing REST APIs we know of trend or end up in these non-ideal states, as well as nearly all *internal* REST APIs.
> 
> <cite>*[GraphQL Introduction](https://facebook.github.io/react/blog/2015/05/01/graphql-introduction.html)* ([cache](/david/cache/8c1e8304e252f607b6814d7c613d53a5/))</cite>

REST permet de gérer la complexité du Web et de sa décentralisation de manière plutôt élégante. Le problème arrive lorsque l’on essaye de l’utiliser dans un contexte où cette complexité devient caduque comme des API internes.

Lorsque vous êtes maîtres du client ET du serveur, un simple service en RPC avec [Nameko](http://nameko.readthedocs.org/en/latest/index.html) ou similaire sera probablement plus pertinent. Cela dit, je suis impatient de voir ce que va donner GraphQL.