Suggestion d'API, architecture

Bonjour tout le monde !

Tout d'abord j'espère ne pas me tromper en postant dans cette partie du forum sachant que ma question est assez vaste^^

Alors, je suis en stage et je dois développer une application Android qui devra se connecter et utiliser une base de données MongoDB de façon sécurisée.

J'ai lu pas mal de doc, que ce soit sur Mongo ou ailleurs et je dois dire que je suis un peu perdu concernant certains éléments.

C'est pourquoi j'aurais aimé avoir l'avis éclairé de personne plus expérimentés sur :
- l'utilisation d'une API est-il nécessaire pour accéder à la DB ? (Pour Mongo ou autre) Pourquoi ?
- Si oui, quelle API me conseillez vous ?

J'ai regardé du côté de Spring qui est très connu, très complet mais assez complexe (même si bien documenté avec de nombreux sujets sur le net).

Par avance merci.

Florian

Tu ne serais pas sur le même projet que StatInfo31 par hasard ?

Citation:

---

Envoyé par Stukas

- l'utilisation d'une API est-il nécessaire pour accéder à la DB ? (Pour Mongo ou autre) Pourquoi ?

---

Oui.
Un accès en direct à une base de données est une faille de sécurité majeure, surtout si le compte utilisé a des droits de modification.
Il est très fortement recommandé de passer par par un niveau d'indirection représenté par des webservices. Ceux-ci peuvent être authentifié (ou non) et réalisent la communication avec la base de données. Cela permet de contrôler ce qui est fait et de ne pas mettre les identifiants de la BDD dans l'application.

Citation:

---

Envoyé par Stukas

- Si oui, quelle API me conseillez vous ?

---

Je ne connais pas d'outils permettant de monter vite des webservices, mais je sais qu'il en existe. Basiquement, c'est une URL appelée et une réponse renvoyée dans un format attendu.

Merci pour cette réponse express !

Eheh non je ne le connais pas même si le sujet se rapproche en effet (contexte, équipe etc) ;)

Je vais donc y allé par étape et commencé avec la base de Spring je pense, j'ai vu des bons tutos sur le site :)

Et petite question plus "personnelle", je vois que tu es développeur mobile, de ton point de vue qu'est-ce qui est le "mieux" lorsque l'on veut développer une appli sur Android et IOS :
- développer les deux en natif
- utiliser un framework ou des outils pour ne développer qu'une seule fois l'appli

Merci encore :)
Florian

Je n'ai jamais utilisé d'outils X-platform.
Au vu des on-dits, je me dirigerai vers Xamarin pour se faire si j'avais le choix.

Je préfère de très loin réaliser des applis natives et ne surtout pas utiliser de WebView vu le nombre absolument incroyable de galères que j'ai vu à son sujet.
Je ne connais pas assez les solutions X-platform pour me prononcer dessus.

OK très bien merci pour ton feedback ;)

C'est une éventualité concernant mon projet mais c'est pas au programme tout de suite x)

MongoDB permet nativement d'être interrogé sous forme d'URLs, dans le plus pur esprit des architectures REST. Derrière il y a HTTP, donc il est forcément possible de gérer l'authentification et/ou le chiffrement.

Ah, merci. C'est intéressant ça :)

Pardon, j'ai confondu avec CouchDB

Arg ok, pas de problèmes, merci quand même ;)

Sinon je me pose pas mal de questions sur Spring, c'est sans doute préférable que je me tourne vers cette partie du forum et ouvrir une nouvelle discussion non ?

Pour avoir travaillé avec Spring, j'avoue que c'est un peu utiliser une bombe nucléaire pour ouvrir une canette de soda... :D
Surtout si c'est juste pour faire une API REST en Java par exemple.

Après côté serveur, il y a des outils incontournables:
* sérialisation en base de données (Hibernate par exemple)
* logging (Log4j par exemple)
* unit-testing (JUnit par exemple)

Et si on parle de serveur Java, les webservice peuvent très bien ne pas être REST du tout et utiliser simplement des jsp ....
Dès qu'on rentre dans REST, les framework "anciens" ont un peu du mal... Par exemple "La page 45 du livre Toto" a normalement (en REST) une URL genre: "/livres/Toto/pages/45"
Et ce genre d'URL a toujours un peu de mal à se faire accepter par des frameworks comme spring.

On peux très bien faire ça avec Spring, la question est plus philosophique.
Tu peux rester standard et utiliser JAX-RS, partir sur un framework comme Spring (en l'occurrence Spring MVC pour gérer des Webservices REST), ou encore sortir encore un peu plus de la norme et utiliser une plateforme comme Play Framework, qui simplifie la tuyauterie.

J'ai vu pas mal de doc sur Hibernate en effet mais j'avais abandonnée l'idée avant de voir qu'il existait en version pour MongoDB.

Spring fait un peu usine à gaz c'est vrai, surtout comparé à Play Framework que j'ai regardé brièvement mais qui me semble plus light ;)


Le choix n'est toujours pas définie donc si vous avez d'autres idées, n'hésitez pas (merci encore) puisque je verrais ensuite avec mes collègues stagiaires ce que l'on choisit.

Florian

Je te dirais bien de partir sur la norme, c'est à dire un serveur d'application style Wildfly ou TomEE, des services REST avec JAX-RS, des EJBs stateless et hibernate en persistance.
Tu auras un bon aperçu de JEE c'est qui est un bon point pour tes futures recherches de boulot.

Si tu veux du plus fun et plus léger, pars sur Playframewok.

Hello, j'espère que vous avez passé un bon week end !

"Plus fun et plus léger", j'aime l'idée^^

Et donc, Play framework permettrait de faire tout ça, gérer les services REST, la persistance des données et la sécurisation des transferts ?

En tout cas, l'équipe commence à regarder ça de plus près mais si c'est le cas, on va partir la-dessus.

PS : nous regardons également, DreamFactory, des connaisseurs ?

Toutes ces technos sont des serveurs d'applications, et donc présentent un intérêt seulement si tu as une vraie couche applicative (i.e des traitements plus ou moins complexes) coté serveur, en amont de ta base de données. Or ce n'est pas vraiment ton besoin de départ si je relis ton message : tu cherches simplement à rendre accessible une BDD depuis un périphérique Android (comme c'est souvent le cas).

Oui en effet, c'est ce que nous avons remarqué avec l'équipe sur ce dernier.

Du coup, on est partis sur quelque chose de plus classique avec PlayFramework.