# evolutions API 2023

## Objectifs
- supprimer le submitter service
- avoid oneof to simplify the API
- garder à l'esprit qu'on utilisera l'option de gRPC transcoding venant avec dotnet 7. Il faut donc avoir des APIs compatibles avec la philosophie d'API REST moderne
- revoir la soumission des taches au niveau du submitter va impliquer aussi de revoir la soumission des taches au niveau du worker (transparent, utilisation des memes interfaces, ajout des nouvelles methodes puis suppression des anciennes)
- se préparer pour les api v4
- appliquer les bonnes pratiques de definition d'API gRPC et REST via le transcoding gRPC

## Ref rest api

- https://hevodata.com/learn/rest-api-best-practices/
- https://learn.microsoft.com/en-us/azure/architecture/best-practices/api-design
- https://github.com/Microsoft/api-guidelines/blob/master/Guidelines.md
- https://stackoverflow.blog/2020/03/02/best-practices-for-rest-api-design/
- https://fr.wikipedia.org/wiki/Representational_state_transfer (Relation entre URI et méthodes HTTP, utiliser le tableau pour y passer toutes les ressources possibles)
- https://docs.adonisjs.com/guides/controllers#nested-resources
- https://cloud.google.com/endpoints/docs/grpc/transcoding?hl=fr#designing_a_transcoding-friendly_api
- https://standards.rest/
- https://protobuf.dev/programming-guides/api/

## Suppression du submitter
1. Proposer des alternatives dans les différents services (API)
2. Implementer dans core
3. Deprécier le submitter
4. Migrer vers les nouveaux services dans Ext (peut etre cassant)
5. Supprimer le submitter service

## Methodes du submitter deja dispo mais avec quelques modifications
### CancelTasks
- use a list of task ids
- previous task cancellation was using a taskfilter (session id or list of tasks and task status)
- maybe include new method to cancel all tasks from a given session id => CancelSession

### CancelSession
- both versions use session id
- no taskfilter in the new version
- previous version also cancelled all tasks of the session

### ListTasks
- Filter not based on a OneOf
- Can filter multiple columns at the same time
- Support order direction
- [wki] allow to continue a previous request (avoids server->client stream)

### ListSessions
- Filter not based on a OneOf
- Can filter multiple columns at the same time
- Support order direction

## Methodes qui devraient etre migrées telles quelles
### WaitForAvailability
- à mettre dans le ResultsService
### WaitForCompletion
- à mettre dans le TasksService
### CreateSession
- à mettre dans le SessionsService

## A migrer

### GetServiceConfiguration
- utilisé pour déterminer la taille d'un chunck, possibilité de le garder tel quel
- [wki] anticiper d'éventuelles évolutions en ayant des champs dynamique type dictionnaire ?

### WatchResults
- peut etre à retravailler
- à migrer dans le ResutlsService

### CountTasks
- Est ce que les CountTasksByStatus du TasksService/SessionsService/ApplicationsService sont des alternatives suffisantes ?

### TryGetResultStream
- il faudra surement changer le nom de la methode et de la requete mais le fonctionnement sera le meme

### TryGetTaskOutput
- nom et requete à changer
- GetTask du TasksService peut etre une alternative

### GetTaskStatus
- nom et requete à changer
- GetTask du TasksService peut etre une alternative

### GetResultStatus
- nom et requete à changer

## Methodes qui vont changer
- CreateSmallTasks
- CreateLargeTasks
- La soumission des taches et des payloads sera dissociée
- creation de methodes dans le ResultsService pour creer des données et soumettre des données [wki] proposer 2 interfaces, avec ou sans chunks ?
- ajouter un nom custom pour les resultats [wki] ajout d'un nom "unique" (unique dans la session)
- creation d'une methode pour soumettre les taches avec les ids des payloads (data créés par la methode mentionnée précédement) au lieu de chunks de données (la payload)

## Qu'est ce que ça va casser ?

- Il faut migrer vers l'utilisation des autres services et non plus le SubmitterService (surtout la partie cliente d'ext dans laquelle il faudra adapter les requetes gPRC aux nouveaux services et interfaces pour récupérer les données)
- S'il manque des APIs il faudra les ajouter
- Du coté worker, il devrait y avoir peu de changement puisqu'ils seront deja intégrés dans le WorkerStreamWrapper. Il suffira de mettre à jour. [wki] sauf pour la création de données et l'envoi des données qui pourraient être exposés en plus de l'api actuelle.