C'est l'outil qu'AWS utilise en interne pour définir leurs API et ensuite générer des SDK dans tous les langages.
Exemple:
$version: "2"
namespace example.weather
service Weather {
version: "2006-03-01"
resources: [City]
operations: [GetCurrentTime]
}
resource City {
identifiers: { cityId: CityId }
read: GetCity
list: ListCities
resources: [Forecast]
}
Les nouvelles API de OpenAI sont disponibles.
Notamment celle de ChatGPT (gpt-3.5) avec un coût par token 10x inférieur!
Whisper est une quand à elle une API de text to speech
Un serveur web qui permet d'accèder à une base PostgreSQL directement via une API REST!
Exemples:
- SELECT avec WHERE 👉
GET /people?age=gte.18&student=is.true
- un JOIN sur la table
directors
👉GET /films?select=title,director:directors(id,last_name)
HTTPie ont lancé un assistant IA pour intéragir avec les API.
En gros on tape un prompt en langage naturel et ça génère la bonne requête
Fetch last release details of httpie/desktop
La meilleure explication que j'ai eu des CORS (Cross Origin Resource Sharing).
Les CORS sont un ensemble de règles envoyées par un serveur dans les header HTTP qui sont ensuite respectées par le navigateur afin d'empêcher un site d'envoyer des requêtes vers un autre site.
Par exemple, un script Javascript qui s'exécute sur https://links.aschen.ovh ne peut pas envoyer une requête sur le domaine gmail.com car les CORS de gmail.com ne l'autorise pas.
(Merci Florian pour le partage)
Un framework pour créer des API REST en codant les contrôleurs et modèles en TypeScript avec des annotations.
Ça génère automatiquement la spec OpenApi et les JsonSchema en plus.
(Merci Bombi pour le partage)
Un article très complet sur l'API Gateway utilisé par Uber.
Ils ont développé leur propre API Gateway qui est en frontal de leurs micro-services écrits dans différents langages.
user access, etc
Les API Gateway peuvent être de simples routeurs mais peuvent aussi aller plus loin en incorporant de la logique métier, comme celle de Uber justement ("low level" vs "feature rich")
Dans le cycle de vie d'une requête, ils ont extraits 4 familles de composants:
- Protocol Manager: responsable de décoder et d'encoder (JSON, Thrift, Protobuf)
- Middleware: briques métier réutilisables (authentification, rate limiting, etc)
- Endpoint Handler: convertit la requête entrante dans le format attendu par le service backend
- Client: envoi la requête au service backend (validation, timeout, retries, etc)
Un article explicatif sur le versionning d'API chez LinkedIn.
Conceptuellement, ils vont dupliquer les ressources en interne en incluant la version de l'API Foo
=> FooResource_v20220201
Ils ont ensuite un service de conversion qui va convertir les ressources dans le dernier format possible pour éviter d'avoir à dupliquer le code.
Utilisation d'un rate limiter pour éviter de se prendre des 429 quand on fait appel à une API externe
Critique constructive de GraphQL, notamment sur la complexité de maintenance et les performances