[REST] Fileupload sous forme d'attributs ou de ressources

Bonjour à tous,

Petite question existentielle que je viens de me poser.
Imaginons un petit exemple. Je veux créer un trombinoscope avec JAX-RS en JEE.
Je vais donc avoir des "personnes" qui vont avoir des "photos" associées.
Ma question est la suivante :
- Dois je créer deux ressources (REST) une pour la "photo" et une pour la "personne" (contenant un identifiant vers la ressource "photo")?
- ou bien une ressources "personne" contenant un attribut de type "file" qui contiendra la photo.

Quelle est pour vous la meilleure solution ? Et bien sûr pourquoi ?
Question supplémentaire : Peut on faire du file upload en JAX-RS 2.0 pur (non dépendant de l'implémentation), tout ce que j'ai trouvé jusque là s'appuie sur une implémentation ou bien le font en découpant carrément le MultiPart avec Httpcommons.

Merci à vous tous pour vos éclaircissements et idées,

Bien à vous,

ZeKiD.

Bonjour !
Je suis un peu jeune dans le développement d'application java EE, mais j'ai ma petite expérience.
J'ai en fait développé une application qui permet de gérer des fichiers (avec des web services REST). Les web services sont consommés par des terminaux Android. Moi j'ai opté pour les noms de fichiers comme attribut.

Pour la persistance des données une méthode. Pour l'envoie ou réception de fichier une autre méthode.
A mon avis cette méthode me permet de réduire le temps d'exécution d'une requête, de simplifier le décodage des données à la réception et surtout me permet de stocker le fichier hors de la base de données facilement.

En ce qui concerne votre FileUpload, je n'ai pas saisi la question. Je l'ai utilisé mais c'est celui intégré dans primefaces. Je n'arrive pas en fait à établir le lien avec
l'implémentation de JAX-RS.

Comme je le disais je suis nouveau en la matière. Si je suis suis out corriger moi, ça m'aidera!

Bien à vous
Habibouss.

Hello,


Pour ma part je m'appuie sur le framework Jersey pour faire quelque chose de similaire. J'ai des users, des photos qui leur sont associées.
Cependant j'ai distingué les deux ressources pour des raisons de performances.

Deux choix sont possibles :

- Gérer l'user complet avec la photo à l'intérieur, auquel cas il faut faire passer le fichier dans le flux json / doc XML donc encodé (base 64 ?).
- Gérer indépendamment les ressources de manière à décorreler les performances, c'est à dire afficher les infos importantes dans un premier temps très rapidement (infos user) et charger en parallèle la photo qui va apparaitre après les infos importante, dans un délais suivant le poids de celle ci

L'avantage selon moi et que dans le cas ou l'on souhaite afficher de l'information, on ne laisse pas l'utilisateur avec un waiter infini (surtout en mobile en Edge...). On lui montre d'abord les infos importantes et la photo vient après.
De plus au niveau du code je trouve cela plus propre, car on peut gérer l'upload et le get de la ressource avec un accept à image/*, ce qui est plus modulaire qu'un flux json / xml avec le fichier encodé à l'intérieur... Mais c'est mon avis ;)