Plusieurs développements, y compris le cloud computing et l'architecture basée sur les microservices, ont été rendus possibles par les API RESTful. Ils ont décrit la communication et l'informatique en ligne comme étant simples. Par conséquent, tout développeur doit comprendre ce qu'est REST , comment il fonctionne, ses avantages et comment créer des services sûrs pour suivre le rythme. Comme ils peuvent les aider à créer des solutions évolutives, simples à entretenir et permettre à leurs produits d'atteindre le monde entier grâce à la puissance d'Internet, de nombreuses entreprises préfèrent les développeurs ayant une compréhension REST.
Comment se préparer aux questions d'entretien liées à l'API RESTful ?
Les questions les plus fréquentes des entretiens avec l'API REST concernant les services Web RESTful lors des entretiens avec l'API REST, et les demandes concernant la bibliothèque JAX-RS et les services Web RESTful construits à l'aide du framework Spring MVC, sont mentionnées dans la section ci-dessous. Avant de passer ou de programmer un entretien, il est crucial de se préparer à toutes les questions d'entretien API REST mentionnées.
Qu'est-ce que le REPOS ?
REST, décrivant le transfert d'état représentatif, est responsable du développement d'applications de site Web établies sur le protocole HTTP. REST spécifie plusieurs règles que l'utilité liée au site Web doit attacher pour le croire. Les suggestions garantissent des méthodes HTTP standardisées entre le serveur et l'utilisateur pour transmettre virtuellement les soumissions.
Qu'est-ce qu'une API REST ?
L'API RESTful permet un échange d'informations en ligne sécurisé entre deux systèmes informatiques. Pour mener à bien diverses activités, la majorité des applications métier échangent des données avec d'autres programmes internes et externes. Par exemple, lorsque votre système de comptabilité interne partage les informations sur les employés avec le système bancaire externe pour générer des fiches de paie. Cela peut être fait avec l'API REST car ces informations sont personnelles et les normes logicielles de l'API REST sont sécurisées, efficaces et dignes de confiance.
L'API RESTful est connue sous le nom d'API liée à REST d'une manière ou d'une autre. Toutes les données sont considérées comme des ressources dans l'API REST et déterminées par une unité constante standard précise appelée (URI). L'API Twitter crée un tweet en tant que ressource à laquelle l'utilisateur peut accéder et récupérer. Grâce à l'API Twitter, les utilisateurs peuvent facilement publier des tweets.
Quels sont les principes du REST ?
Le client-serveur permet une séquence de réponses qui sont utilisées pour transmettre entre le consommateur et le serveur. Les deux peuvent envoyer et accepter des réponses l'un de l'autre. Cette vision claire de la méthode client-serveur permettra aux deux forces d'opérer indépendamment l'une de l'autre.
Système en couches
Entre le client et le serveur d'API, les couches sont des serveurs. Ces différents serveurs effectuent plusieurs tâches, telles que la détection des spams et l'amélioration des performances. Les messages envoyés entre le client et le serveur d'interface de programmation d'application (API) ne sont pas affectés par l'ajout ou la suppression de couches car REST (état de représentation) utilise une architecture modulaire.
Interface uniforme
Le client et le serveur doivent toujours utiliser le même protocole pour toutes les communications. Ce protocole est HTTP REST. Étant donné que chaque application utilise le même langage pour demander et fournir des données, une interface uniforme facilite les intégrations.
Apatride
Dans une communication sans état, le serveur ne conserve aucun enregistrement des réponses qui ont déjà été envoyées. Chaque réponse possède l'entrée complète nécessaire pour conclure les transactions. Il améliore l'interprétation en diminuant la charge du serveur et l'utilisation de la mémoire. Cela supprime également le risque qu'une demande échoue en raison d'informations incomplètes.
Cacheable
Les clients peuvent mettre en cache toutes les ressources pour augmenter les performances en utilisant les réponses des serveurs qui indiquent si une ressource peut ou non être mise en cache. REST contient également la condition facultative suivante.
Code à la demande
La réponse d'une API peut contenir du code exécutable que les utilisateurs peuvent exécuter. Ainsi, l'application cliente peut exécuter le code sur son propre backend.
Quelle est la différence entre AJAX et REST ?
La différence entre AJAX et REST est :
AJAX | LE REPOS |
Les objets XMLHttpRequest sont utilisés en Ajax pour envoyer des requêtes au serveur. Cependant, le code de JavaScript fournit les réponses pour modifier dynamiquement la page en cours. | L'utilisation des ressources est importante pour la structure de l'URI et le modèle demande/réponse. utilisé par REST. |
Ajax est un ensemble de technologies qui permet la mise à jour dynamique de l'interface utilisateur sans recharger la page. | Les utilisateurs peuvent demander des données ou des informations aux serveurs en utilisant le style d'architecture logicielle REST. |
Ajax élimine la communication asynchrone entre le serveur et l'utilisateur. | REST exige une communication entre le serveur et l'utilisateur. |
Comment fonctionne l'architecture des microservices ?
Une méthode architecturale pour développer des applications cloud est appelée microservices. Chaque application est composée d'un certain nombre de services, chacun s'exécutant dans un processus séparé et interagissant avec les autres via des API. Une méthode de création d'applications connue sous le nom d'"architecture de microservices" est devenue une bonne pratique au fil du temps. Les composants de l'architecture de microservices sont basés sur les besoins de l'entreprise.
- Clients
Les demandes sont envoyées par de nombreux utilisateurs utilisant divers appareils.
- Fournisseurs d'identité
Vérifiez l'identité des utilisateurs ou des clients et fournissez des jetons de sécurité.
- Passerelle API
Les demandes des clients sont traitées via API Gateway.
- Contenu statique
Tout le matériel du système est contenu dans un contenu statique.
- La gestion
Détermine les défaillances et équilibre les services entre les nœuds.
- Découverte de services
Un outil pour déterminer le chemin de communication entre les microservices.
- Réseau de diffusion de contenu
Un réseau distribué de serveurs proxy et de centres de données associés.
- Service à distance
Les informations stockées sur un réseau d'appareils informatiques peuvent être consultées à distance à l'aide d'un service à distance.
Quelles sont les méthodes HTTP prises en charge par REST ?
Les méthodes prises en charge par REST HTTP sont :
- GET - la méthode la plus largement utilisée dans les sites Web et les API, GET reçoit des ressources du serveur de données spécifique.
- POST - via la méthode POST, les données sont envoyées au serveur API pour mettre à jour la ressource. Lorsqu'un serveur reçoit les données, il les stocke dans le corps de la requête HTTP.
- PUT - il envoie des données à l'API afin de créer et de mettre à jour les ressources.
- SUPPRIMER - comme son nom l'indique, cette méthode est utilisée pour supprimer les ressources à des URL spécifiques.
- OPTIONS - il détaille les techniques prises en charge.
HEAD - les métadonnées sur l'URL de la requête sont renvoyées. Examinons la situation du point de vue d'un seul enregistrement. Disons qu'il y avait un enregistrement pour un travailleur avec le numéro d'employé 1. Les activités suivantes indiqueraient chacune quelque chose de différent.
POST - puisque nous récupérons des informations pour l'employé 1, qui a déjà été créé, cela n'est pas applicable.
GET - cela serait utilisé pour récupérer les informations de l'employé via l'API Web RESTful, et le numéro d'employé serait 1.
PUT - à l'aide de l'API Web RESTful, PUT serait utilisé pour mettre à jour les informations de l'employé afin de refléter l'employé n° 1.
SUPPRIMER - cette fonction est utilisée pour supprimer les informations de l'employé avec le numéro d'employé 1.
Quelle est la différence entre PUT et POST ?
La différence entre PUT et Post est la suivante :
- PUT - identifie précisément et particulièrement un fichier ou une ressource à un URI fourni (identificateur de ressource uniforme). PUT modifie un fichier existant s'il existe à cet identificateur de ressource uniforme - URI. PUT forme un fichier s'il en existe déjà un. De plus, PUT est idempotent, ce qui suggère qu'il n'a pas encore d'impact sur les fichiers à quelle fréquence il est utilisé.
- POST - il envoie des données à un identifiant de ressource uniforme distinct - URI et s'attend à ce que le fichier de ressources y gère la demande. À ce moment, le serveur du site Web peut décider de ce qu'il convient de faire avec les données dans le contexte du fichier sélectionné. De plus, la stratégie POST n'est pas idempotente, ce qui signifie que si vous l'utilisez plus d'une fois, elle recommencera à générer de nouveaux fichiers.
Quelle est la différence entre l'architecture SOA monolithique et l'architecture de microservices ?
Les applications monolithiques ont un rythme de développement très lent et sont constituées d'unités interconnectées et indivisibles. Des services plus petits et peu connectés constituent la SOA, qui a également un développement limité.
Les microservices sont des services incroyablement petits, faiblement connectés et autonomes avec un cycle de développement itératif rapide.
Qu'est-ce que l'URI ?
Un identificateur de ressource uniforme est appelé URI. Un URI dans REST est une chaîne qui désigne la ressource d'un serveur Web. Chaque ressource a un URI distinct qui, lorsqu'il est utilisé dans une requête HTTP, permet aux clients de la cibler et d'effectuer des actions dessus. L'adressage est le processus qui consiste à diriger le trafic vers une ressource à l'aide de son URI.
Le format de l'URI est :
<protocole>://<service-name>/<ResourceType>/<ResourceID>
Il existe deux types d'URI
1. URL - les informations sur la récupération d'une ressource à partir de son emplacement sont disponibles dans Uniform Resource Locator.
Les URL contiennent des informations sur le nom d'hôte du réseau (sampleServer.com) et le chemin d'accès au contenu (/samplePage.html), et elles commencent par un protocole (tel que FTP, HTTP, etc.). Il peut également avoir des critères de recherche.
2. URN - en utilisant un nom à la fois distinctif et durable, un nom de ressource uniforme identifie la ressource.
L'emplacement de la ressource sur Internet n'est pas nécessairement spécifié par l'URN. Ils servent de modèles aux autres analyseurs à utiliser lors de l'identification des ressources.
Chaque fois qu'un URN identifie un document, il peut être rapidement converti en URL à l'aide d'un "résolveur" afin qu'il puisse ensuite être téléchargé.
Quelles sont les fonctionnalités des services Web RESTful ?
Ces fonctionnalités sont présentes dans chaque service Web RESTful :
- Le modèle de communication client-serveur est la base du service.
- Le service utilise le protocole HTTP pour récupérer des données/ressources, exécuter des requêtes et effectuer d'autres tâches.
- "Messagerie" est la méthode utilisée pour communiquer entre le client et le serveur.
- Le service peut accéder aux ressources via l'utilisation d'URI.
- Il adhère à l'idée d'apatridie, dans laquelle la demande et la réponse du client ne dépendent pas des autres, et offre ainsi une certitude totale que les données nécessaires seront obtenues.
- Pour réduire les appels au serveur pour le même type de requêtes répétitives, ces services utilisent également l'idée de la mise en cache.
- Ces services peuvent également implémenter le modèle architectural REST à l'aide des services SOAP.
Que sont les codes d'état HTTP ?
Les codes standard utilisés dans l'état HTTP correspondent aux états d'achèvement des tâches serveur établis. Par exemple, le statut HTTP 404 indique que le serveur ne dispose pas de la ressource demandée.
Examinons les codes d'état HTTP et comprenons leur signification :
- 200 - OK, le succès est évident.
- 201 - lorsqu'une requête POST ou PUT crée avec succès une ressource, le code de réponse est 201 - CREATED. À l'aide de l'en-tête d'emplacement, renvoyez l'URL de la ressource nouvellement générée.
- 304 - dans le cas de requêtes GET conditionnelles, le code d'état 304 NON MODIFIÉ est utilisé pour économiser la bande passante du réseau. Les corps de réponse doivent être nuls. Les dates, lieux et autres informations doivent figurer dans les en-têtes.
- 400 - BAD REQUEST indique qu'une entrée non valide, telle que des données manquantes ou une erreur de validation, a été fournie.
- 401 - INTERDIT indique que l'utilisateur n'a pas accès à la méthode utilisée, comme la suppression de l'accès sans droits d'administrateur.
- 404 - ERREUR indique que la méthode demandée est introuvable.
- 409 - CONFLITS Lorsque la méthode est exécutée, cela indique un problème conflictuel, tel que l'insertion d'entrées en double.
- 500 - Le code INTERNAL SERVER ERROR indique que le serveur a lancé une exception pendant l'exécution de la méthode.
Pouvez-vous me dire les inconvénients des services Web RESTful ?
Les inconvénients des services Web RESTful sont :
- Les sessions dans les services Web RESTful ne peuvent pas être maintenues car l'assistant s'en tient au concept d'apatridie.
- Les restrictions de sécurité et de protection ne sont pas essentielles pour REST. Certains protocoles sont utilisés pour des mesures de sécurité. Cela fournira un avertissement qui peut être utilisé pour déterminer les normes de protection et de sécurité à choisir, par exemple - les authentifications SSL/TLS.
Faire la différence entre SOAP et REST ?
La différence entre SOAP et REST est :
DU SAVON | LE REPOS |
Un protocole appelé SOAP est utilisé pour implémenter des services Web | REST est un modèle de conception architecturale pour développer des services Web |
Les directives fournies par SOAP sont destinées à être strictement respectées | REST décrit les critères, cependant, ils n'ont pas besoin d'être pleinement respectés |
Étant donné que le client et le serveur SOAP sont plus étroitement liés, il est comparable aux programmes de bureau avec des contrats stricts à cet égard | Le client REST est plus adaptable qu'un navigateur et est indépendant de la conception du serveur tant qu'il respecte les normes de communication nécessaires |
Seul le transfert XML entre le client et le serveur est pris en charge par SOAP | Plusieurs types de données, y compris XML, JSON, MIME, texte, etc., sont fournis par REST |
Les lectures SOAP ne peuvent pas être mises en cache | Les requêtes de lecture REST peuvent être mises en cache |
Les interfaces de service sont utilisées par SOAP pour exposer la logique des ressources | La logique de ressource est exposée à l'aide de REST à l'aide de l'URI |
SOAP est plus lent | REST est plus rapide |
En tant que protocole, SOAP établit ses propres protocoles de sécurité | REST ne prend en charge que les précautions de sécurité basées sur le protocole d'implémentation |
Bien que SOAP ne soit pas fréquemment choisi, il est utilisé lorsqu'un transport de données avec état et une plus grande fiabilité sont requis | De nos jours, REST est souvent préféré par les développeurs car il offre plus d'évolutivité et de maintenabilité |
Qu'est-ce qui constitue les composants de base de la réponse HTTP ?
La réponse HTTP comporte quatre composants principaux qui sont les suivants :
- Code d'état de réponse - affiche le code d'état du serveur en réponse à la demande de ressource. Exemple : une erreur côté client est représentée par 400, alors qu'une réponse positive est représentée par 200.
- Version HTTP - la version du protocole HTTP est indiquée par la version HTTP.
- En-tête de réponse - les métadonnées du message de réponse sont contenues dans cette section. Les données peuvent être utilisées pour fournir des éléments tels que la longueur du contenu, le type, la date de réponse, le type de serveur, etc.
- Corps de la réponse - la ressource ou le message que le serveur a réellement renvoyé est contenu dans le corps de la réponse.
Quelles sont les différences entre WebSockets et REST ?
Voici quelques différences entre WebSockets et REST mentionnées ci-dessous :
REST est basé sur les opérations CRUD, tandis que WebSocket est un protocole de bas niveau basé sur les concepts de socket et de port, qui sont le mécanisme de transport fondamental.
Alors que les applications RESTful doivent concevoir leurs opérations en fonction des verbes et HTTP, WebSocket exige l'utilisation de l'adresse IP et des informations de port, qui sont des détails de niveau inférieur pour toute application. WebSocket est un protocole avec état, tandis que REST est construit sur un protocole sans état, ce qui signifie que ni le client ni le serveur n'ont besoin de se connaître.
Contrairement à REST, qui est basé sur HTTP, qui peut évoluer horizontalement, les connexions WebSocket peuvent évoluer verticalement sur un seul serveur. La communication basée sur REST est comparativement plus chère, mais la communication WebSocket est moins chère.
Pouvons-nous implémenter la sécurité de la couche de transport (TLS) dans REST ?
Nous pouvons, oui! La communication du client-serveur dans REST est cryptée à l'aide de TLS, qui permet également à l'utilisateur de déterminer le serveur. Puisqu'il remplace le Secure Socket Layer (SSL), il s'agit d'une forme de communication sécurisée entre l'utilisateur et le serveur. Étant donné que HTTPS fonctionne bien avec Secure Socket Layer (SSL) et Transport Layer Security (TLS), il est utile lors de la création de services Web RESTful. Ici, il est important de noter que le REST entre dans les aspects du protocole qu'il utilise. Par conséquent, les protections de sécurité reposent sur le protocole REST.
Quelle est la taille maximale de la charge utile pouvant être envoyée dans les méthodes POST ?
L'ampleur de la charge utile qui peut être transportée dans la méthode post est théoriquement illimitée. Cependant, il est important de se rappeler que les charges utiles plus importantes consomment plus de bande passante et prennent plus de temps à traiter, ce qui affecte la réactivité du serveur.
Répertorier les annotations clés présentes dans l'API JAX-RS
- Chemin - cela détaille le chemin relatif de l'URI (Uniform Resource Identifier) de la ressource REST.
- GET - cet indicateur de la méthode de requête correspond à HTTP GET. Ils gèrent les requêtes GET.
- POST - cet indicateur de la méthode de requête correspond à HTTP POST. Ils traitent les demandes POST.
- PUT - cet indicateur de la méthode de requête correspond aux requêtes HTTP PUT. Ils traitent les demandes PUT.
- DELETE - il est défini comme le désignateur de la méthode de requête utilisée pour HTTP DELETE. Ils traitent les requêtes DELETE.
- HEAD - cet indicateur de la méthode de requête correspond à HTTP HEAD. Ils traitent les demandes de la HEAD.
- PathParam - les développeurs peuvent utiliser ce paramètre de chemin URI (Uniform Resource Identifier) pour extraire les paramètres des URI pour les classes/méthodes de ressources.
- QueryParam - la classe de ressource/les méthodes peuvent utiliser ces requêtes qui ont été extraites de l'URI (Uniform Resource Identifier) par le développeur à l'aide de ce paramètre de requête URI (Uniform Resource Identifier).
- Produit - les présentations de ressources MIME qui sont créées et envoyées à l'utilisateur en réponse sont spécifiées ici.
- Consomme - cela détaille les présentations de ressources MIME que le serveur acceptera ou utilisera lorsqu'il les recevra de l'utilisateur.
Définir RestTemplate au printemps
La classe principale pour l'accès des utilisateurs aux services RESTful est appelée RestTemplate. En utilisant les restrictions REST, la communication avec le serveur est établie. Ceci est comparable aux différentes sections de modèles proposées par Spring, telles que JdbcTemplate et HibernateTemplate. Le RestTemplate donne aux méthodes la possibilité de communiquer à l'aide du modèle d'URI (Uniform Resource Identifier), des paramètres de chemin d'URI (Uniform Resource Identifier), des types de requête/réponse, des objets de requête, etc. Il fournit des détails d'implémentation de haut niveau pour les méthodes HTTP comme GET , POST, PUT, etc.
Cette section de Spring 4.3 propose des annotations souvent utilisées comme @GetMapping, PutMapping, @PostMapping, etc. Avant cela, Spring propose l'interprétation @RequestMapping pour spécifier les méthodes utilisées.
A quoi sert @RequestMapping ?
- Les demandes sont mappées à des méthodes de gestionnaire particulières à l'aide de l'annotation.
- Dispatcher Servlet gère tout le routage des applications Web entrantes dans Spring. En utilisant des gestionnaires de requêtes, il décide quel contrôleur parmi tous est destiné à traiter la requête lorsqu'il la reçoit. Toutes les classes avec l'annotation @Controller sont analysées par le Dispatcher Servlet.
Les annotations @RequestMapping, qui sont définies dans les méthodes et les classes du contrôleur, sont essentielles au processus de routage des requêtes.
Répertoriez les outils ou l'API pour développer ou tester l'API Web
À l'aide de divers outils tels que Postman, Swagger, etc., les services Web RESTful peuvent être testés. Postman possède de nombreuses fonctionnalités, notamment la possibilité d'envoyer des requêtes aux points de terminaison, d'afficher des réponses pouvant être converties en JSON ou XML et d'analyser les paramètres de requête tels que les en-têtes et les paramètres de requête, ainsi que les en-têtes de réponse. Comme Postman, Swagger offre un certain nombre de fonctionnalités ainsi que la possibilité de documenter les terminaux . Nous pouvons également tester les performances et la charge des API à l'aide d'outils tels que Jmeter.
Qu'est-ce que la mise en cache ?
Lorsqu'une réponse de serveur est mise en cache, elle est enregistrée afin qu'une nouvelle copie puisse être utilisée chaque fois que nécessaire au lieu d'avoir à générer à nouveau la même réponse. Cette technique allège non seulement la charge du serveur, mais améliore également ses performances et son évolutivité. La réponse ne peut être mise en cache que par le client et seulement pendant une courte période.
L'en-tête des ressources et une description concise sont inclus ci-dessous afin que la procédure de mise en cache puisse les identifier :
- Date et heure de création de la ressource
- Date et heure de la mise à jour des ressources, qui conserve généralement les informations les plus récentes
- En-tête pour le contrôle du cache
- Date et heure auxquelles la ressource mise en cache cessera de fonctionner
- L'âge qui établit le point de départ du moment où la ressource a été récupérée
Quelles sont les meilleures ressources pour apprendre l'API REST ?
Il existe de nombreuses ressources disponibles pour apprendre l'API REST pour développer des sites Web et des applications mobiles . Les 5 meilleurs sont listés ci-dessous :
Services Web RESTful
Afin de débuter le développement d'une application avec consommation d'API, ce guide intitulé RESTful Web Services wonder de Leonard Richardson sera un grand atout à cet égard. Surtout si vous êtes débutant et que vous souhaitez comprendre les bases des services de site Web Representational State Transfer (REST). La ressource a révélé le fonctionnement du transfert d'état représentatif (REST) et de nombreux autres services Web essentiels avec des exemples. Il n'est basé sur aucun langage de programmation, de sorte que la compréhension des API RESTful ne sera liée à aucun langage de programmation.
Tutoriel API REST
Le didacticiel de l'API REST est une excellente ressource en ligne pour apprendre le transfert d'état représentatif (REST) si vous n'êtes pas un livre ou un lecteur. Cette ressource vous aidera à apprendre REST du début à la fin, couvrant tous les aspects de base. Ce didacticiel commence par l'introduction du transfert d'état représentatif (REST), puis suivra le chemin des exemples concernant les stratégies et les connaissances liées à HTTP, et ainsi de suite.
Livre de règles de conception d'API REST
Il s'agit également d'un excellent livre de ressources pour les conseils de transfert d'état représentatif (REST), car l'auteur du livre Mark Masse transmet ses expériences et les stratégies qu'il a prises et qui ont contribué à la création de son application à l'aide de l'API REST. Dans cette ressource, il a discuté des pratiques de conception des URI d'application, des approches de transmission des métadonnées via des en-têtes HTTP et des types de supports pouvant être utilisés. En outre, comment impliquer l'innovation dans la conception des méthodes de soumission HTTP et des codes d'état de réponse.
Newsletter hebdomadaire des développeurs d'API
Il existe une ressource géniale appelée la newsletter hebdomadaire des développeurs d'API ; il s'agit d'une ressource à jour pour apprendre l'API RESTful car elle est fortement concentrée sur la technique, la structure, l'expansion et l'architecture de l'API pour les applications Web et les applications mobiles. La newsletter est spécialement conçue pour les développeurs, les chefs de projet et les architectes.
Repos assuré
Celui-ci est un support de test REST open source chanceux pour les personnes expérimentées avec un langage de programmation appelé Java. Cette ressource facilite la procédure de test et de validation des processus d'API RESTful. REST-Assured élimine également la nécessité de créer du code passe-partout pour tester des réactions complexes et aide la syntaxe BDD.
En un mot
Pour être concluant, l'article mentionné ci-dessus partage les questions d'entretien de l'API REST. Il couvre toutes les questions d'entretien de l'API REST pour les personnes qui vont postuler ou ont postulé pour des emplois similaires nécessitant des connaissances sur l'API RESTful. Ce sont les questions les plus courantes qu'un recruteur peut vous poser lors d'un entretien d'embauche. Consultez également les ressources mentionnées avant de vous asseoir pour un entretien final.
De plus, si vous souhaitez créer votre application de site Web ou votre application mobile, AppMaster peut être votre choix ultime. C'est une plate-forme sans code qui vous permettra de créer toutes sortes d'applications en toute simplicité.https://appmaster.io/fr/blog/quest-ce-que-le-glisser-deposer-et-comment-vous-aide-t-il-a-obtenir-le-logiciel-personnalise-que-vous- les méthodes de glisser-déposer et ne nécessitent aucune expérience ou connaissance préalable en matière de codage. Découvrez les offres dès aujourd'hui.