Projet API REST Generaliste publique

[Guiguiabloc]

Bonjour à tous,

Depuis longtemps je code mes propres APIs pour ma domotique et au fil des lectures sur les forums, je me rend compte que de simples informations basiques dont tout le monde a besoin demande ou un développement personnel de l'utilisateur sur sa box, ou des appels a différents services divers et variés.
Cela a était plus flagrant ce soir quand je cherchais juste a savoir si aujourd'hui était un jour férié. Ca a l'air con, mais cette simple interrogation demande de fouiller le net et de tripoter un peu de code.

Je me demandais donc si la mise a disposition d'une API publique REST pour répondre a des besoins primaires vous serez utile ?
Exemple avec la sollicitation ci dessus, vous faite une requete de type "http://api.public.fr/ferie/maintenant" et on vous répond juste si aujourd'hui c'est férié ou pas (ou http://api.public.fr/ferie/25-12-2014 et on vous dit si c'est férié).
Bien sur c'est un simple exemple et ca peut se décliner a d'autres choses (vacances scolaires, etc...)
Bref, est-ce un service qui vous serez utile ? Si oui, qu'en attendez vous d'autres ?

Donc avant que je réfléchisse plus sérieusement à coder ce genre de service, j'attends votre avis

Amicalement

[domotics]

Oui, mais pas un service en cloud ;-(

[Guiguiabloc]

Qu'est ce que tu entends par "pas un service en cloud" ?

[domotics]

Bien il faudrait que l'API puisse s'installer sur un raspberry en local. Et qu'on puisse la mettre à jour à chaque fois qu'une nouvelle version sort.

[vosmont]

Hello,

l'idée est intéressante, mais effectivement seulement si c'est local, voire cloud personnel.

Du coup, je me demande si le besoin n'est pas de lier la box à un service tel "Cozy cloud" (je n'ai pas testé mais le concept est pas mal; à chaque fois, la démo en ligne ne marche pas)
http://cozy.io/

Ça devrait pouvoir remplacer Google Calendar et avec le App store et la possibilité de développer ses propres applications, les nouveaux besoins doivent pouvoir être couverts.

En tout cas, le concept de own cloud me semble être le meilleur compromis mais reste tout de même un peu geek

[Guiguiabloc]

Bien il faudrait que l'API puisse s'installer sur un raspberry en local. Et qu'on puisse la mettre à jour à chaque fois qu'une nouvelle version sort.

Le principe était plutot d'offrir un simple service externe pour les gens qui n'ont pas Rasp ou envie d'installer une API locale.
Cela permettait de se baser sur une sorte d'opendata qui délivrait une information simple.
Si tu prends la météo par exemple, tu ne l'installes pas en local, tu interroges un webservice externe. L'idée était plutot de centraliser ce type de webservice externe pour répondre à des besoins primaires.

Après, je peux très bien diffuser le code de l'api pour que les plus "geeks" se l'installe en local :p

[Guiguiabloc]

Hello,

l'idée est intéressante, mais effectivement seulement si c'est local, voire cloud personnel.

Du coup, je me demande si le besoin n'est pas de lier la box à un service tel "Cozy cloud" (je n'ai pas testé mais le concept est pas mal; à chaque fois, la démo en ligne ne marche pas)
http://cozy.io/

Ça devrait pouvoir remplacer Google Calendar et avec le App store et la possibilité de développer ses propres applications, les nouveaux besoins doivent pouvoir être couverts.

En tout cas, le concept de own cloud me semble être le meilleur compromis mais reste tout de même un peu geek

Ca dépasse le concept de l'API. Ce que j'envisage c'est un webservice simple et accessible qui évite de partir dans des usines à gaz et des appels à 50 trucs différents pour un besoin simple du style : "est-ce férié aujourd'hui ?" "est-ce les vacances scolaires ?" "est-ce qu'il fait nuit ?" etc...

[vosmont]

Dans tous les cas, il faudra faire un appel http et parser la réponse XML ou JSON.
Je ne suis pas sûr que soit soit plus simple que décrire la fonction (en LUA ou autre) qui traite le besoin initial.

En tout cas ça m'a donné envie de tester Cozy Cloud

[Guiguiabloc]

Dans tous les cas, il faudra faire un appel http et parser la réponse XML ou JSON.
Je ne suis pas sûr que soit soit plus simple que décrire la fonction (en LUA ou autre) qui traite le besoin initial.

euh... traiter simplement une réponse standardisée d'une API ça prend 2 lignes... Et reproductible pour tout les appels que tu fais.
Ecrire en LUA une fonction différente à chaque fois que t'as besoin d'une information basique, je suis vraiment pas sur que ce soit plus simple.
D'un coté tu as toujours la même structure de parsing et tu changes juste l'url d'appel, de l'autre tu te tapes 20 lignes de fonction (voir plus) pour faire la même chose, et pour chaque fonction différente (et que tu devras transposé probablement dans un autre langage si ta box a un langage différent).
La force d'un webservice est justement d'éviter toutes ses lignes de code puisque le traitement est toujours le meme (puisque la réponse est un standard)

[Calcipher]

Bonjour,

Je trouve l'idée très bonne...

l'idée est intéressante, mais effectivement seulement si c'est local, voire cloud personnel.

Au contraire à mon avis, le but est de pouvoir récupérer simplement des données "publiques".
Si les infos sont locales et personnelles, on vas les récupérer directement et pas s'embêter à monter un serveur REST...

Mais ça suppose donc d'avoir quelque part un serveur récupérant, formatant et mettant à disposition ces données.
Tout ça me fait penser à ce qui se fait pour les programmes TV (kazer ou équivalent), où il y a un standard de fait (xmltv).

[Guiguiabloc]

Au contraire à mon avis, le but est de pouvoir récupérer simplement des données "publiques".
Si les infos sont locales et personnelles, on vas les récupérer directement et pas s'embêter à monter un serveur REST...

Mais ça suppose donc d'avoir quelque part un serveur récupérant, formatant et mettant à disposition ces données.
Tout ça me fait penser à ce qui se fait pour les programmes TV (kazer ou équivalent), où il y a un standard de fait (xmltv).

Merci Calcipher, tu as parfaitement compris le principe

[olebrun]

Salut Guigui,

Moi ça m'intéresse. Je ne sais pas comment tu souhaiterai fonctionner mais s'il était possible de définir une structure standard pour que chacun (ou certain) puisse ajouter au système de nouvelles fonctionnalités sous forme de plugin ou autre pour permettre de scinder le boulot (maintenir un tas de scrapper doit être assez galère).

Sinon pour les données : tendance du prix du fioul, données tempo, météo