Exactement le genre d'usage de TypeScript que je déteste.
Ce qui semble être une bonne idée au départ devient un méli-mélo de complexité impossible à comprendre du premier coup et qui finalement apporte une valeur limitée et un faux sentiment de sécurité, du fait que le schéma JSON de l'API appelée peut changer du jour au lendemain.
Si vous avez la chance de consommer une API REST qui dispose d'une documentation OpenAPI exhaustive, alors je préfère l'usage de librairies type json-schema-to-ts pour inférer le type des requêtes et réponses à partir du schéma, et créer un petit adapteur (une fonction) qui prendra le type de la requête en argument (incluant body, query params, et headers si nécessaire) et qui retournera le type de la réponse.
Ça permet un bien meilleur contrôle selon moi, et le code n'en est que plus explicite.
Une API native de nos navigateurs qui permet de savoir si l'utilisateur est actif sur la page et s'il a interagit avec la page au moins une fois depuis son chargement.
Un outil qui permet de trouver les failles d'APIs HTTP.
D'abord en cherchant les documentations type Swagger ou OpenAPI exposées publiquement par erreur, puis en "attaquant" chaque service pour trouver ceux qui ne sont pas suffisamment sécurisés où qui exposent des données sensibles.
L'idée est évidemment de l'utiliser sur vos propres APIs pour en renforcer la sécurité.
Via https://korben.info/autoswagger-outil-gratuit-trouve-failles-api.html
Un outil pour mocker les appels réseau effectués par Node à la volée. Pratique pour tester du code qui appelle des services HTTP externes.
Même si je n'utilise pas Elysia.js du fait que je n'utilise pas (encore ?) Bun, j'aime beaucoup la façon dont cette librairie a été conçue. Tout est très intuitif, et il y a un gros effort effectué pour encourager les bonnes pratiques (input validation, documentation, client type-safe, etc.).
A essayer !
Et si vous préférez attendre une plus grande stabilité/maturité au niveau de l'API, je pense que d'ici quelques mois, 1 an max ce sera bon. Mais la documentation est déjà très instructive à parcourir.
Un exemple de l'utilisation de tRPC (ici avec Deno) pour échanger entre le client et le serveur tout en bénéficiant du typage des deux côtés.
Une alternative à Swagger UI pour documenter vos APIs à partir d'une spécification OpenAPI.
Une alternative open-source à Postman.
Une API météo gratuite et sans besoin de compte.
Ghost dispose maintenant d'une API pour interagir (voir remplacer complètement) l'interface d'administration.
Un micro framework Node.js (~260 lignes de code) pour faire des micro API.
Encore un CMS "headless" (sans rendu, juste une API JSON).
Quelques bonnes pratiques pour la création d'APIs.
Un CMS sans front. Uniquement une API. Et à vous de construire votre site en appelant l'API. Il y a des librairies toutes faites pour les langages les plus courants (Ruby, JS, C#, PHP, Python, Go - étrangement pas Java).
Par contre c'est payant. Si quelqu'un connaît un équivalent gratuit et open-source je suis preneur.
Implementation PHP de l'API de Mastodon.
Je viens de découvrir cette API qui est très intéressante. Elle permet de communiquer facilement entre une page et une iframe qui y est contenue même si les deux ne partagent pas le même domaine. Même chose avec les popups.
Quelques bonnes pratiques pour la mise en place d'une API.