www.meetup.com/CaenCamp
@caencamp
(Application Programming Interface)
RESTful
HATEOAS
...
* les liens comme relation entre ressources (Hypermedia)
* l’URI comme identifiant des ressources
* les verbes HTTP comme identifiant des opérations
(GET, POST, PUT, PATCH, DELETE)
* les réponses HTTP comme représentation des ressources
Mais ...
Liste des albums: GET /api/albums
Ajout d'un album à une playlist: POST /api/playlists/:id/albums
Création d'une playlist: POST /api/playlists
Liste des playlists : GET /api/playlists
albums?artist=xenia
ou
artists/xenia/albums
- en XML
- en json
- Trop d'informations, et on gaspille bêtement de la bande passante et de la mémoire.
- Trop peu d'informations, et on est obligé de multiplier les requêtes.
Il faut souvent le créer indépendamment de l'API
Il faut la maintenir en parallèle de l'évolution de l'API
On peut utiliser des outils : Swagger, API Blueprint, Open API ...
L'utilisateur ajoute un album à une playlist
playlist.ajouterUnAlbum()
playlist.addAlbum()
POST api/playlist/:id/albums
data query language
{
getPlaylists(id: “1”) {
title
album
}
}
Créé en 2012 par Facebook, c'est open-source depuis 2015.
Github propose son API graphQL depuis 2016
SpotifyLink
Artist
Album
Playlist
Release
DDD, ubiquitous language, mock
coordination des développements back et front
Album {
idMb
cover
title
artists
publicationDate
releases
similars
spotifyLinks
}
Artist {
idMb
type
name
country
}
Release {
support
label
date
}
type Album {
# Id musicBrainz
idMb
# Url for album cover
cover
# Album's main title
title
# Artists credited to the album
artists
# First publication date
publicationDate
# The different releases of the album
releases
# If you liked it, you might also like this albums
similars
# Spotify listening links
spotifyLinks
}
type Album {
# Id musicBrainz
idMb: String! ,
# Url for album cover
cover: String!,
# Album's main title
title: String!,
# Artists credited to the album
artists: [Artist],
# First publication date
publicationDate: Date!,
# The different releases of the album
releases: [Release],
# If you liked it, you might also like this albums
similars: [Album],
# Spotify listening links
spotifyLinks: [SpotifyLink],
}
query {
__type(name: "Artist") {
name
fields {
name
description
type {
name
kind
ofType {
name
kind
}
}
}
}
}
Pour un projet d'API publique ... pas certain, ou en plus d'une version REST
Pour un projet back(s)/front(s) dont l'API n'est pas publique : un gros OUI
- approche graph first
- DDD nommage des mutations
- documentation et découverte
- économie de réseau
- approche composant (redux, style inline, HOC sur une requête nommée stockée côté serveur)
- à priori mature (Facebook, Github)
- pas de data (microservice, base64)
- un peu trop de magie