Retour aux annonces
VersionSDK5 min de lecture

IaGenify SDK 0.2 : des ressources fichier et stockage plus claires.

La version 0.2 clarifie les objets publics des fichiers et des stockages connectés : l’application s’appuie sur des identifiants stables et des opérations, pas sur des détails d’implémentation.

iagenifysdkjavascriptfilesstorage

Un SDK forme la frontière entre un service et les applications qui l’utilisent. Cette frontière est plus simple quand ses objets décrivent les opérations utiles, au lieu de refléter l’organisation interne du stockage. IaGenify SDK 0.2 clarifie cette distinction pour les fichiers et le stockage connecté.

Un fichier est une ressource, pas un chemin serveur

Une application doit pouvoir identifier, lire, modifier ou supprimer un fichier. Elle n’a pas besoin de connaître le répertoire qui contient actuellement ses octets sur une machine du service. L’objet fichier s’appuie donc sur son identifiant source et sur ses opérations prises en charge.

const file = await api.files.get(sourceId);
console.log(file.sourceId);
file.content = "Revised note";
await file.update();

Des identifiants stables rendent le code portable. La même référence fonctionne dans un outil local, une interface web ou une automatisation, sans apprendre le système de fichiers du serveur.

Le stockage connecté expose des opérations utiles

Une ressource de stockage connecté doit permettre à l’application d’agir sur la connexion. L’objet public expose son identité et les opérations disponibles ; l’application n’a pas besoin d’inspecter les identifiants de connexion pour lister ou utiliser le stockage.

const storage = await api.storage.get({ id: storageId });
console.log(storage.id);
const files = await storage.run({ action: "list", path: "/reports" });

La responsabilité est ainsi claire : l’application choisit une opération et le service utilise la configuration enregistrée pour l’exécuter. Le code appelant n’a pas à recopier les informations de connexion dans son propre état.

Une interface publique plus ciblée est plus facile à maintenir

Quand un SDK renvoie des détails d’implémentation, les applications peuvent en dépendre alors qu’ils n’ont jamais fait partie du contrat stable. Les retirer devient ensuite une rupture. Des objets plus ciblés facilitent la documentation et l’évolution entre runtimes.

Il ne s’agit pas de cacher un comportement utile, mais de l’exposer au bon niveau : des identifiants pour désigner les ressources, des méthodes pour les opérations prises en charge et des résultats sur lesquels l’appelant peut agir.

Le principe derrière la version 0.2

IaGenify SDK 0.2 est une petite version qui porte une idée utile : les objets publics contiennent les informations nécessaires à l’application, sans imposer les détails internes du service.

Un SDK fiable fournit des identifiants stables et des actions claires, tandis que le service garde la maîtrise de son implémentation.

Questions fréquentes

Pourquoi utiliser un identifiant de fichier plutôt qu’un chemin ?

L’identifiant reste valable entre runtimes et évolutions du stockage ; un chemin décrit une seule implémentation.

L’application a-t-elle besoin des identifiants du stockage connecté ?

Le service utilise la connexion configurée. Le code de l’application appelle les opérations de stockage sans recopier les identifiants.

La version 0.2 modifie-t-elle le contenu des fichiers ?

Non. Elle clarifie les objets publics et les références utilisées par les applications.

Quel est le principe général ?

Garder un contrat SDK centré sur des ressources identifiables et des opérations prises en charge.

Retour aux annonces