🛜 scrumia-ktor

Ce dont il est responsable

Neuf règles de refus couvrant les huit familles que Ktor possède — routage, négociation de contenu, client HTTP, authentification, client de test, configuration serveur, WebSockets et SSE, observabilité — plus une neuvième qui nomme la dissociation entre le statut HTTP et la discipline d'erreur typée de l'application. Livre une compétence ktor-audit qui audite une base de code existante contre les neuf, et un mappage find-spec pour les clés auxquelles le module répond. Les règles portent sur une bibliothèque, pas sur une pile : un service pur-JVM, un client Ktor-sur-Android, une appli navigateur Kotlin/JS activent scrumia-ktor seul.

Ce qu'il refuse

Une route enregistrée hors de l'arbre routing {} de l'application. Un Json.decodeFromString sur call.receiveText() dans une application qui installe ContentNegotiation. Un HttpClient construit à l'appel. Une vérification dans le handler. Un test qui ouvre un vrai port. Un port ou un secret en littéral dans Kotlin. Un websocket qui ne lit jamais de frame, ou une boucle SSE qui ne se reconnecte jamais. Un println dans un handler. Un Result.failure dont le corps est r.status — le canal est celui de l'application, pas celui du réseau.

L'hypothèse qu'il fait

Présume que la documentation de la bibliothèque est la citation de chaque règle — pas d'articles de blog, pas de tutoriels, pas de patterns communautaires. Coûte de la discipline à chaque installation de plugin, à chaque construction d'HttpClient, et à chaque route, et le rend en surface qu'un seul lecteur peut voir de bout en bout. La dissociation entre statut HTTP et sémantique d'effet est la ligne que le module existe pour tenir : scrumia-ktor possède la bibliothèque, le paradigme d'erreur typée appartient au module suivant.

Ses compétences

• ktor-audit

Étiquettes

• scrumia
• ktor
• http
• server
• client
• kotlin

Ce à quoi il se branche

L'installer

Lire le source sur GitHub