Dive into Go API
Photo par Jakob Owens on Unsplash
Depuis plusieurs années maintenant, j’écris quotidiennement mes programmes dans le langage de programmation Go.
Bon, en fait, je fais aussi pas mal d’assembleur, beaucoup de C, de l’OpenCL, du GLSL, du Verilog, un peu de Cuda, de Python, de JavaScript, du PHP et de Shell, mais pour mes projets qui concernent un API RESTful et un serveur, je fais essentiellement du Go.
En particulier si ma façon d’écrire ce type de code a évolué ces dernières années, j’en suis venu à concevoir une méthode de développement de serveur d’API RESTful qui me correspond bien. Je doute qu’elle puisse répondre aux besoins de tout un chacun, mais peut-être que cela pourrait vous inspirer ?
Dans cet article, je vous propose de partager un petit template de code, qui me sert de base à presque tous mes projets de service HTTP d’API.
Sommaire
- Pourquoi RESTful, et qu’est-ce que cela implique ?
- Gorilla/mux pour traiter les routes
- Faut-il utiliser le package encoding/json ?
- Quelle base de données choisir ? (SQL, Key/Value, Fichier)
- Sécuriser les requêtes
Pourquoi RESTful, et qu’est-ce que cela implique ?
Il y a plusieurs architectures possibles pour proposer une API HTTP, dont, entre autres :
- XML-RPC
- SOAP
- JSON-RPC
- REST
- gRPC
REST signifie “REpresentational State Transfer”. Cette architecture a été décrite par Roy Fielding dans une dissertation pour son doctorat en philosophie des sciences de l’information et informatique (excusez du peu).
Je vous invite à lire ce document. Il n’est pas rare de trouver ici et là des divergences sur ce qu’est véritablement une API REST, et je trouve qu’il n’est pas déraisonnable, loin s’en faut, de se référer au document original.
Pour faire simple et résumer, REST est une architecture qui décrit la relation entre un logiciel client et le logiciel serveur. Du côté du serveur, les données sont mises à disposition du client au travers de représentations de données dans des formats simples comme JSON ou XML par exemple. REST propose de définir comment sont présentés les données, et comment on peut les modifier par l’intermédiaire d’opérations simples.
L’interface REST proposée doit alors être uniforme. Cela signifie que vos données sont présentées sous forme de resources et collections de resource.