Pausa caffè #31. 9 errori professionali che ogni sviluppatore dovrebbe evitare Perché l'architettura API REST sta guadagnando popolarità?

9 errori di carriera che ogni sviluppatore di software dovrebbe evitare

Fonte: Infoworld Siamo onesti. Alcuni di voi hanno iniziato a imparare a programmare perché voi o i vostri genitori pensavate che sarebbe stato più facile per voi guadagnare un sacco di soldi. A scuola non eri particolarmente interessato ai computer e non ti piaceva molto lo sviluppo di software. Se questo è vero, significa che sarai sempre un programmatore mediocre. Sì, guadagnerai bei soldi perché il nostro settore lo favorisce, ma questo articolo non fa per te. Ma se da bambino venissi punito per aver smontato dei dispositivi elettronici per capire come funzionavano... Se passassi mezza notte su Internet per imparare a creare un videogioco... Se passassi del tempo prezioso libero imparando cosa nessuno te lo ha chiesto... questo articolo è per te. Devi cambiare la percezione della tua carriera. Non scrivi più codice per divertimento: lo fai per soldi. Per divertimento, puoi sostenere i tuoi progetti personali. Ma per favore assicurati almeno di goderti il ​​tuo lavoro quotidiano. In caso contrario, trova un posto migliore, se possibile. Il tuo obiettivo dovrebbe essere quello di aprire il tuo fondo pensione, investire tutti i tuoi soldi al netto delle tasse, comprare una casa, un'auto e fare quello che vuoi. Forse viaggiare. Allo stesso tempo, devi pensare alla tua carriera, non solo al tuo lavoro attuale. Per fare ciò, è necessario evitare nove trappole, di cui parleremo ora.

Insidia n. 1: non restare legati a una tecnologia troppo a lungo

Capisco. Ti piace C# o Java o JavaScript, Python o Cobol. Ma la maggior parte delle tecnologie ha un ciclo di vita caratterizzato da adozione, picco, outsourcing, nicchia e obsolescenza. Voglio dire, se avessi conosciuto Cobol negli anni '80, sarebbe stato fantastico. Ma oggigiorno i programmatori Cobol non guadagnano molto. Cioè il punto è che conoscendo un solo linguaggio di programmazione, prima o poi dovrai tagliare le spese, trasferirti in una città più economica, perché guadagnerai di meno.

Trappola n. 2: non essere un monopolista IT

Devi proteggere i tuoi investimenti. Potrebbe sembrare che tu abbia solo bisogno di diventare un esperto nelle tecnologie che attualmente dominano il mercato. Ma poi dovrai affrontare molta concorrenza. Inoltre, quando la domanda per la tua specialità diminuisce, dovresti già avere un piano di uscita in atto. Ad esempio, ero un fanatico del C++ quando è uscito Java. Ho imparato Java. Qualche anno fa tutti iniziarono a parlare di Ruby come della nuova stella nascente tra i linguaggi di programmazione. E ad un certo punto sembrava che Perl avrebbe raggiunto lo stesso livello di Java. Prevedere il futuro è difficile, quindi coprire le proprie scommesse è il modo più sicuro per garantire rilevanza nel mercato del lavoro.

Trappola n. 3: non aggrapparsi alle mode passeggere

Prima o poi la magia scompare. Le persone non assumeranno sviluppatori Groovy o Ruby. Se il tuo capo ti consente di utilizzare lingue preesistenti in un progetto, sarà perché non gli interessa o è semplicemente ignorante. Sicuramente, impara e usa la tecnologia più recente. Preparati a essere uno dei primi a conoscerli e a diventarne un esperto. D'altra parte, preparati anche ad apportare cambiamenti drastici se la domanda per la tua specialità diminuisce. Ci sono sempre altre nuove tecnologie di cui innamorarsi, che si tratti di un linguaggio o di un database.

Insidia n. 4: allergia alle regole

Ogni organizzazione, non importa quanto grande o piccola, ha le proprie regole d'ufficio. Dovrai studiarli e seguirli. Altrimenti diventerai una pedina nel gioco di qualcun altro o ti ritroverai isolato nella squadra. Se sei interessato a una carriera e a relazioni produttive sul lavoro, impara a seguire le tattiche difensive nelle regole dell’ufficio.

Trappola n. 5: disinteresse per gli affari

"Sono solo uno sviluppatore, non mi interessano gli affari." Questa è una strada che non porta da nessuna parte. Devi imparare a contare. La tua azienda sta andando bene? Quali sono i suoi principali obiettivi aziendali? Quali sono i suoi progetti più importanti? In che modo la tecnologia o il software aiutano a raggiungerli? Come si inserisce la vostra azienda nel settore in generale? Se non conosci le risposte a queste domande, finirai per lavorare su progetti non importanti per persone non importanti in aziende non importanti per una somma di denaro relativamente insignificante.

Insidia n. 6: la mentalità della “solidarietà sindacale”

Quando ero giovane, uno dei miei colleghi era un uomo che pianificava quasi tutto con sei mesi di anticipo. Ha commesso l'errore di andare in vacanza, quindi ho finito l'intero progetto in due settimane, ma gli ho lasciato un pezzo su cui lavorare. Mi aspettavo che ne fosse felice. Si è scoperto che non era felice. Tutto è finito con lui che ha sfruttato ogni opportunità per farmi licenziare. Questo è diventato il suo obiettivo principale. Si è persino lamentato di me con il nostro nuovo direttore. Ovviamente ho fatto tutto il mio lavoro. Ero un innovatore. Trovavo sempre nuovi modi per fare le cose meglio e più velocemente e risolvere i problemi. È andato in pensione poco dopo che ero partito per un altro lavoro. Diverse volte l'ho visto in un bar e abbiamo fatto finta di non conoscerci. Questa non sarebbe l'ultima volta che mi imbatterei in questo tipo di lavoro: "Fai le cose lentamente o le cose peggioreranno." Il mio consiglio: scrivi il codice corretto, ma sii preparato agli imprevisti. Se il problema non si risolve, lascia la porta sbattuta: la tua azienda non è l’unica sul mercato.

Insidia n. 7: non conosci il tuo valore

"Non sono qui per i soldi." Bene, allora prenditi un hobby. Non andare al lavoro ogni giorno pensando al tuo prossimo stipendio. Inoltre non dovresti andare a lavorare se guadagni il 50% in meno di chiunque altro. Conosci il tuo valore e non sottovalutarlo.

Trappola n. 8: trattare il proprio lavoro come un lavoro

"È solo un lavoro." No, questo è un passo nella tua carriera. Non farai questo lavoro per sempre. Allora cosa puoi imparare qui? Quale sarà il tuo prossimo passo? Dove vuoi finire alla fine? In che modo questo lavoro ti aiuterà a raggiungere questo obiettivo? Aumenta la tua consapevolezza di ciò che ti circonda. Questo ti servirà bene a lungo termine. Non è solo un lavoro, è un viaggio.

Trappola n. 9: pensi che sia solo una questione di soldi

Ai venditori piace dire: “Lavoro se lanci una moneta”. Sì, ma a meno che tu non lavori nelle vendite, nessuno vuole lavorare con qualcuno che fa quel lavoro solo per soldi. So che voglio lavorare solo con qualcuno che sia responsabile del proprio lavoro. E tu? D’altra parte, non è necessario essere insopportabilmente responsabili. Se tutto ciò che ti preoccupa veramente è l'eterno dibattito su linguette o lacune, potresti aver bisogno di prendere un sedativo.

Perché l'architettura API REST sta guadagnando popolarità?

Fonte: DZone La comunicazione istantanea è una cosa straordinaria. Siamo tutti abituati al fatto di poter comunicare istantaneamente con qualsiasi parte del mondo. Dai computer desktop o dai dispositivi mobili possiamo acquistare, pubblicare, allegare e selezionare qualsiasi cosa, ovunque. Siamo connessi gli uni agli altri e al mondo come mai prima d’ora. Ma come avviene questo? Come arrivano i dati a noi “da lì”? I dispositivi e le applicazioni comunicano tra loro utilizzando un'interfaccia di programmazione dell'applicazione o API. Questo è esattamente il motore “sotto il cofano”. È sempre dietro le quinte e tendiamo a considerarlo qualcosa di ordinario, ma è l'API che crea tutta l'interattività su cui contiamo.

Cos'è un'API?

In poche parole, un'API è un messenger che accetta richieste, dice al sistema cosa vuoi fare e quindi ti restituisce una risposta. Per un esempio visivo, immagina l'API come un cameriere in un ristorante. Immagina di essere seduto a un tavolo, con in mano un menu e che la cucina faccia parte del sistema che preparerà il tuo ordine. L'API è il collegamento che trasmetterà il tuo ordine alla cucina e consegnerà il cibo al tavolo.

Facciamo un esempio reale:

Conosciamo tutti il ​​processo di ricerca dei voli online e sappiamo che per prenotare un volo dovremo interagire con il sito web della compagnia aerea. Accedi al loro database per vedere se i posti sono disponibili in una data specifica e quali costi puoi aspettarti in base ai requisiti del tuo volo. Ma cosa succede se non utilizzi il sito web di una compagnia aerea che ha accesso diretto alle informazioni? Cosa succede se utilizzi un servizio di prenotazione online che raccoglie informazioni da diverse compagnie aeree? Il servizio interagisce con l'API della compagnia aerea, dove l'API è l'interfaccia che, come il nostro disponibile cameriere, richiede informazioni al servizio online sulla prenotazione del posto e sulla scelta del pasto o sulle preferenze del bagaglio da parte del passeggero. L'API quindi prende la risposta della compagnia aerea e la restituisce al servizio online, che mostra le informazioni al passeggero. Più o meno lo stesso processo si verifica tra tutte le altre applicazioni, dati e dispositivi. Hanno tutti API che consentono ai computer di controllarli e questo alla fine crea comunicazione.

Quali tipi di API esistono?

L'architettura API può essere implementata in due modi principali: uno di questi modi di implementare il trasferimento delle informazioni è SOAP e l'altro modo principale è REST. Abbiamo già stabilito che le API forniscono la comunicazione tra due applicazioni. Ora impareremo come si inseriscono esattamente SOAP e REST nell'architettura di comunicazione.

API SOAP

SOAP (Simple Object Access Protocol) è un servizio web che segue specifiche con determinati principi di comunicazione stabiliti tra un organismo centrale chiamato W3C e un insieme centrale di specifiche. Questo set include:

• SAPONE
• WSDL
• UDDI

SOAP è un protocollo che definisce il modo in cui due applicazioni comunicheranno tra loro. Due applicazioni devono seguire un formato comune quando comunicano tra loro e questo formato comune deve essere basato sul linguaggio XML. L'XML nelle API SOAP deve essere conforme allo standard dei messaggi SOAP, che è costituito da busta, intestazione e corpo.

API REST

Questo è un concetto di servizi web molto importante ma spesso frainteso, quindi decifriamo cosa significa REST o API RESTful. REST è un servizio Web che avvia la comunicazione tra due applicazioni utilizzando i propri principi di architettura. L'architettura REST è uno stile architettonico che non segue alcun protocollo, non esistono specifiche rigide e non esiste un'autorità centrale che controlli le specifiche. Ciò rende REST versatile per l'utilizzo o la creazione di qualsiasi tipo di servizio. Quando questi principi vengono applicati durante la creazione di un servizio web, otteniamo un servizio web RESTful. Ora andiamo un po' più in profondità e scopriamo i principi su cui si basa l'architettura REST.

Interfaccia unificata

In un'architettura RESTful, tutto può essere considerato una risorsa. Ad esempio, se stai tentando di creare un'applicazione per un sistema di gestione dei dipendenti. Questa applicazione può essere sviluppata utilizzando qualsiasi linguaggio, su qualsiasi piattaforma e per qualsiasi piattaforma. Allo stesso modo, qualsiasi database può essere utilizzato per gestire servizi interni. Il concetto di risorsa nell'API REST implica che l'utente possa definire qualsiasi informazione o modulo come risorsa. Dato un sistema di gestione dei dipendenti, il creatore può definire la risorsa del dipendente, i dipartimenti e qualsiasi altro modulo utilizzato nell'applicazione.

Apolide

In un'architettura RESTful, tutte le risposte e richieste e tutte le comunicazioni tra i server sono senza stato. Ciò significa che il server non mantiene lo stato corrente del sistema, il client può inviare una richiesta che si completa. E questa richiesta non dipende da nessuna delle richieste precedenti. Ad esempio, se stai facendo acquisti online e aggiungi articoli al tuo carrello, il server non manterrà lo stato del tuo carrello, quindi ogni volta che un utente invia una richiesta al server, conterrà lo stato del carrello nel momento in cui è stata fatta la richiesta. Quando è senza stato, non vi è alcun sovraccarico per il server per archiviare o mantenere la sessione, quindi migliora le prestazioni del servizio web.

Funzionalità di memorizzazione nella cache

Nell'ultimo protocollo, abbiamo notato che nell'architettura RESTful il server non salva lo stato della sessione, tutto il caching avviene sul lato client. Ogni volta che un client invia una richiesta al server, il server restituisce una risposta che contiene i dati effettivi e altri metadati che indicano al client se deve archiviare la risposta localmente o meno.

Sistema multilivello

I principi REST affermano che ogni volta che c'è comunicazione tra un client e un server, possono esserci più livelli tra di loro e questi livelli possono essere utilizzati per implementare molteplici scopi come la traduzione dei messaggi, il miglioramento delle prestazioni, la memorizzazione nella cache e una varietà di altre cose. Ogni livello di comunicazione ha un compito specifico. Con più livelli di comunicazione, il sistema funziona in modo efficiente, migliorando velocità e durata.

Codice su richiesta

Questa è una limitazione facoltativa dei servizi Web RESTful che funziona quando l'utente invia una richiesta per ricevere una risposta. La risposta può eseguire codice lato client. Questo principio espande la funzionalità della comunicazione.

Perché le API REST vengono utilizzate sempre più spesso?

REST è per la maggior parte più facile da usare, più flessibile e presenta numerosi vantaggi rispetto a SOAP. Ad esempio, non sono necessari strumenti costosi per interagire con qualsiasi servizio web. L'architettura REST è più semplice, può essere facilmente personalizzata e non richiede competenze particolari durante la creazione di un modello di comunicazione. È efficiente da utilizzare perché può utilizzare il lato client del server per archiviare informazioni relative al client. REST utilizza formati di messaggio più piccoli e fornisce interazioni più veloci perché non richiede un'elaborazione dispendiosa in termini di tempo. REST è anche più vicino ad altre tecnologie web per quanto riguarda la filosofia del design.

SAPONE o RIPOSO?

Per i requisiti di una tipica applicazione web, SOAP è spesso eccessivo. REST è una soluzione più semplice che ha tutto ciò di cui hai bisogno quando un'applicazione web necessita di un'API. Tuttavia, ci sono momenti in cui l'API deve essere un po' più complessa per eseguire le attività. Ad esempio, se è necessaria un'API per le richieste automatizzate, un'API SOAP sarebbe una scelta migliore per quello scenario. In poche parole, scegli SOAP se il problema è ampio e complesso e scegli REST se hai bisogno di una soluzione semplice.