Pause café #31. 9 erreurs de carrière que tout développeur devrait éviter. Pourquoi l’architecture API REST gagne-t-elle en popularité ?

9 erreurs de carrière que tout développeur de logiciels devrait éviter

Source : Infoworld Soyons honnêtes. Certains d’entre vous ont commencé à apprendre la programmation parce que vous ou vos parents pensiez qu’il serait plus facile pour vous de gagner beaucoup d’argent. À l’école, vous n’aimiez pas vraiment les ordinateurs et vous n’aimiez pas vraiment le développement de logiciels. Si cela est vrai, cela signifie que vous serez toujours un programmeur médiocre. Oui, vous gagnerez beaucoup d’argent car notre industrie le privilégie, mais cet article n’est pas pour vous. Mais si, enfant, vous étiez puni pour avoir démonté des appareils électroniques afin de comprendre comment ils fonctionnaient... Si vous passiez la moitié de la nuit sur Internet pour apprendre à créer un jeu vidéo... Si vous passiez un temps libre précieux à apprendre ce qu'est un jeu vidéo. personne ne vous l'a demandé... cet article est pour vous. Vous devez changer la perception de votre carrière. On n'écrit plus du code pour le plaisir : on le fait pour l'argent. Pour vous amuser, vous pouvez soutenir vos projets personnels. Mais s'il vous plaît, assurez-vous d'apprécier au moins votre travail quotidien. Sinon, trouvez un meilleur endroit si possible. Votre objectif devrait être d’ouvrir votre fonds de retraite, d’y investir tout votre argent après impôt, d’acheter une maison, une voiture et de faire ce que vous voulez. Peut-être voyager. En même temps, vous devez penser à votre carrière, et pas seulement à votre emploi actuel. Pour ce faire, vous devez éviter neuf écueils, dont nous allons maintenant parler.

Piège n°1 : Ne restez pas trop longtemps dans une technologie

Je comprends. Aimez-vous C# ou Java ou JavaScript, Python ou Cobol. Mais la plupart des technologies ont un cycle de vie d’adoption, de pointe, d’externalisation, de niche et d’obsolescence. Je veux dire, si vous aviez connu Cobol dans les années 1980, ça aurait été cool. Mais les programmeurs Cobol ne gagnent pas beaucoup d’argent de nos jours. Autrement dit, le fait est que ne connaissant qu'un seul langage de programmation, vous devrez tôt ou tard réduire vos dépenses, déménager dans une ville moins chère, car vous gagnerez moins.

Piège n°2 : ne pas être un monopole informatique

Vous devez couvrir vos investissements. Il peut sembler qu’il suffit de devenir un expert des technologies qui dominent actuellement le marché. Mais vous serez alors confronté à une forte concurrence. De plus, lorsque la demande pour votre spécialité diminue, vous devriez déjà avoir un plan de sortie en place. Par exemple, j’étais un connaisseur du C++ lorsque Java est sorti. J'ai appris Java. Il y a quelques années, tout le monde a commencé à parler de Ruby comme de la nouvelle étoile montante parmi les langages de programmation. Et à un moment donné, il semblait que Perl atteindrait le même niveau que Java. Il est difficile de prédire l’avenir, c’est pourquoi se couvrir est le moyen le plus sûr de garantir sa pertinence sur le marché du travail.

Piège n°3 : ne vous accrochez pas aux modes

Tôt ou tard, la magie disparaît. Les gens n'embaucheront pas de développeurs Groovy ou Ruby. Si votre patron vous autorise à utiliser des langages existants sur un projet, ce sera soit parce qu'il s'en fiche, soit parce qu'il est simplement ignorant. Bien sûr, apprenez et utilisez les dernières technologies. Soyez prêt à être l’un des premiers à les connaître et à devenir un expert en la matière. D’un autre côté, soyez également prêt à apporter des changements drastiques si la demande pour votre spécialité diminue. Il y a toujours d’autres nouvelles technologies dont on peut tomber amoureux, qu’il s’agisse d’un langage ou d’une base de données.

Piège n°4 : l’allergie aux règles

Chaque organisation, quelle que soit sa taille, a ses propres règles de fonctionnement. Vous devrez les étudier et les suivre. Sinon, vous deviendrez un pion dans le jeu de quelqu'un d'autre ou vous vous retrouverez isolé dans l'équipe. Si vous êtes intéressé par une carrière et des relations productives au travail, apprenez à suivre les tactiques défensives des règles de bureau.

Piège n°5 : le désintérêt pour les affaires

"Je ne suis qu'un développeur, les affaires ne m'intéressent pas." C'est une route qui ne mène nulle part. Vous devez apprendre à compter. Votre entreprise se porte bien ? Quels sont ses principaux objectifs commerciaux ? Quels sont ses projets les plus importants ? Comment la technologie ou les logiciels contribuent-ils à les atteindre ? Comment votre entreprise s’intègre-t-elle dans l’ensemble du secteur ? Si vous ne connaissez pas les réponses à ces questions, vous finirez par travailler sur des projets sans importance pour des personnes sans importance dans des entreprises sans importance pour une somme d'argent relativement insignifiante.

Piège n°6 : la mentalité de « solidarité syndicale »

Quand j’étais jeune, un de mes collègues était un homme qui planifiait presque tout six mois à l’avance. Il a fait l'erreur de partir en vacances, alors j'ai terminé tout le projet en deux semaines, mais je ne lui ai laissé qu'un seul morceau sur lequel travailler. Je m'attendais à ce qu'il en soit heureux. Il s'est avéré qu'il n'était pas content. Tout s'est terminé avec lui qui a utilisé toutes les occasions pour me faire virer. C'est devenu son objectif principal. Il s'est même plaint de moi auprès de notre nouveau directeur. Bien sûr, j'ai fait tout mon travail. J'étais un innovateur. Je trouvais toujours de nouvelles façons de faire les choses mieux et plus rapidement et de résoudre les problèmes. Il a pris sa retraite peu de temps après mon départ pour un autre emploi. Plusieurs fois, je l’ai vu dans un café et nous avons fait comme si nous ne nous connaissions pas. Ce ne serait pas la dernière fois que je rencontrais ce type de travail : « Faites les choses lentement ou les choses empireront. » Mon conseil : écrivez du code correct, mais préparez-vous à l'inattendu. Si le problème ne peut être résolu, partez en claquant la porte : votre entreprise n’est pas la seule sur le marché.

Piège n°7 : vous ne connaissez pas votre valeur

"Je ne suis pas là pour l'argent." Eh bien, adoptez un passe-temps. N'allez pas au travail tous les jours en pensant à votre prochain salaire. Vous ne devriez pas non plus aller travailler si vous gagnez 50 % de moins que tout le monde. Connaissez votre valeur et ne la sous-estimez pas.

Piège n°8 : traiter votre travail comme un travail

"C'est juste un travail." Non, c'est une étape dans votre carrière. Vous ne resterez pas éternellement dans ce métier. Alors, que pouvez-vous apprendre ici ? Quelle sera votre prochaine étape ? Où voulez-vous finir finalement ? Comment ce travail vous aidera-t-il à atteindre cet objectif ? Augmentez votre conscience de votre environnement. Cela vous sera très utile à long terme. Ce n'est pas seulement un travail, c'est un voyage.

Piège n°9 : Vous pensez que ce n’est qu’une question d’argent

Les vendeurs aiment dire : « Je travaille si vous lancez une pièce de monnaie. » Oui, mais à moins que vous ne travailliez dans la vente, personne ne veut travailler avec quelqu'un qui exerce ce métier juste pour l'argent. Je sais que je veux seulement travailler avec quelqu'un qui est responsable de son travail. Et toi? D’un autre côté, il n’est pas nécessaire d’être insupportablement responsable. Si tout ce qui vous inquiète vraiment est l'éternel débat sur les languettes ou les lacunes, vous devrez peut-être prendre un sédatif.

Pourquoi l’architecture API REST gagne-t-elle en popularité ?

Source : DZone La communication instantanée est une chose étonnante. Nous sommes tous habitués au fait que nous pouvons communiquer instantanément n’importe où dans le monde. Depuis un ordinateur de bureau ou un appareil mobile, nous pouvons acheter, publier, joindre et sélectionner n'importe quoi, n'importe où. Nous sommes connectés les uns aux autres et au monde comme jamais auparavant. Mais comment cela se produit-il? Comment les données nous parviennent-elles « à partir de là » ? Les appareils et les applications communiquent entre eux à l'aide d'une interface de programmation d'applications, ou API. C'est exactement le moteur « sous le capot ». C'est toujours en coulisses, et nous avons tendance à le considérer comme quelque chose d'ordinaire, mais c'est l'API qui crée toute l'interactivité sur laquelle nous comptons.

Qu'est-ce qu'une API ?

En termes simples, une API est un messager qui accepte les demandes, indique au système ce que vous voulez faire, puis vous renvoie une réponse. Pour un exemple visuel, imaginez l'API comme un serveur dans un restaurant. Imaginez que vous êtes assis à une table, tenant un menu entre vos mains, et que la cuisine fait partie du système qui préparera votre commande. L'API est le lien qui transmettra votre commande à la cuisine et livrera les plats à table.

Prenons un exemple réel :

Nous connaissons tous le processus de recherche de vols en ligne et savons que pour réserver un vol, nous devrons interagir avec le site Web de la compagnie aérienne. Vous accédez à leur base de données pour voir si des sièges sont disponibles à une date précise et à quels coûts vous pouvez vous attendre en fonction des besoins de votre vol. Mais que se passe-t-il si vous n’utilisez pas le site Web d’une compagnie aérienne offrant un accès direct aux informations ? Que se passe-t-il si vous utilisez un service de réservation en ligne qui collecte des informations auprès de différentes compagnies aériennes ? Le service interagit avec l'API de la compagnie aérienne, où l'API est l'interface qui, comme notre serveur serviable, demande au service en ligne des informations sur les réservations de sièges et le choix du passager en matière de repas ou de préférences en matière de bagages. L'API prend ensuite la réponse de la compagnie aérienne et la renvoie au service en ligne, qui affiche les informations au passager. Le même processus se produit entre toutes les autres applications, données et appareils. Ils disposent tous d’API qui permettent aux ordinateurs de les contrôler, ce qui crée finalement une communication.

Quels types d’API existe-t-il ?

L'architecture API peut être implémentée de deux manières principales : l'une de ces méthodes de mise en œuvre du transfert d'informations est SOAP, et l'autre méthode principale est REST. Nous avons déjà établi que les API assurent la communication entre deux applications. Nous allons maintenant apprendre comment exactement SOAP et REST s'intègrent dans l'architecture de communication.

API SOAP

SOAP (Simple Object Access Protocol) est un service Web qui suit des spécifications avec certains principes de communication établis entre un organisme central appelé W3C et un ensemble de spécifications de base. Cet ensemble comprend :

• SAVON
• WSDL
• UDDI

SOAP est un protocole qui définit la manière dont deux applications communiqueront entre elles. Deux applications doivent suivre un format commun lorsqu'elles communiquent entre elles, et ce format commun doit être basé sur le langage XML. Le XML dans les API SOAP doit être conforme à la norme de message SOAP, qui comprend l'enveloppe, l'en-tête et le corps.

API REST

Il s'agit d'un concept de services Web très important mais souvent mal compris, alors décryptons ce que signifie REST ou RESTful API. REST est un service Web qui initie la communication entre deux applications en utilisant ses propres principes d'architecture. L'architecture REST est un style architectural qui ne suit aucun protocole, il n'y a pas de spécifications strictes et il n'y a pas d'autorité centrale qui contrôle les spécifications. Cela rend REST polyvalent pour utiliser ou créer tout type de service. Lorsque ces principes sont appliqués lors de la création d'un service Web, nous obtenons un service Web RESTful. Allons maintenant un peu plus en profondeur et découvrons les principes sur lesquels repose l'architecture REST.

Interface unifiée

Dans une architecture RESTful, tout peut être considéré comme une ressource. Par exemple, si vous essayez de créer une application pour un système de gestion des employés. Cette application peut être développée en utilisant n’importe quel langage, sur n’importe quelle plateforme et pour n’importe quelle plateforme. De même, n’importe quelle base de données peut être utilisée pour gérer les services internes. Le concept de ressources dans l'API REST implique que l'utilisateur peut définir n'importe quelle information ou n'importe quel module comme ressource. Étant donné un système de gestion des employés, le créateur peut définir la ressource employé, les départements et tout autre module utilisé dans l'application.

Apatride

Dans une architecture RESTful, toutes les réponses et demandes, ainsi que toutes les communications entre les serveurs, sont sans état. Cela signifie que le serveur ne maintient pas l'état actuel du système, le client peut envoyer une requête qui se complète elle-même. Et cette demande ne dépend d’aucune des demandes précédentes. Par exemple, si vous faites des achats en ligne et ajoutez des articles à votre panier, le serveur ne conservera pas l'état de votre panier. Ainsi, chaque fois qu'un utilisateur soumettra une demande au serveur, celui-ci contiendra l'état du panier au moment de l'achat. une demande a été faite. Lorsqu'il est sans état, le serveur n'a aucune surcharge pour stocker ou maintenir la session, ce qui améliore donc les performances du service Web.

Capacité de mise en cache

Dans le dernier protocole, nous avons remarqué que dans l'architecture RESTful, le serveur ne sauvegarde pas l'état de la session, toute la mise en cache se fait côté client. Chaque fois qu'un client envoie une requête au serveur, le serveur renvoie une réponse contenant les données réelles ainsi que d'autres métadonnées indiquant au client s'il doit stocker la réponse localement ou non.

Système à plusieurs niveaux

Les principes REST stipulent que chaque fois qu'il y a une communication entre un client et un serveur, il peut y avoir plusieurs couches entre eux, et ces couches peuvent être utilisées pour mettre en œuvre plusieurs objectifs tels que la traduction de messages, l'amélioration des performances, la mise en cache et bien d'autres choses. Chaque niveau de communication a une tâche spécifique. Avec plusieurs couches de communication, le système fonctionne efficacement, améliorant ainsi la vitesse et la durabilité.

Code sur demande

Il s'agit d'une limitation facultative des services Web RESTful qui fonctionne lorsque l'utilisateur soumet une demande pour recevoir une réponse. La réponse peut exécuter du code côté client. Ce principe étend la fonctionnalité de la communication.

Pourquoi les API REST sont-elles de plus en plus utilisées ?

REST est pour la plupart plus facile à utiliser, plus flexible et présente de nombreux avantages par rapport à SOAP. Par exemple, vous n'avez pas besoin d'outils coûteux pour interagir avec un service Web. L'architecture REST est plus simple, peut être facilement personnalisée et ne nécessite pas de compétences particulières lors de la création d'un modèle de communication. Son utilisation est efficace car il peut utiliser le côté client du serveur pour stocker des informations relatives au client. REST utilise des formats de message plus petits et offre des interactions plus rapides car il ne nécessite pas de traitement fastidieux. REST est également plus proche des autres technologies Web en ce qui concerne la philosophie de conception.

SAVON ou REPOS ?

Pour les exigences d'une application Web typique, SOAP est souvent excessif. REST est une solution plus simple qui contient tout ce dont vous avez besoin lorsqu'une application Web a besoin d'une API. Cependant, il arrive parfois que l’API doive être un peu plus complexe pour accomplir des tâches. Par exemple, si une API est requise pour les requêtes automatisées, une API SOAP serait un meilleur choix pour ce scénario. En termes simples, choisissez SOAP si le problème est important et complexe, et choisissez REST si vous avez besoin d'une solution simple.