Kaffeepause Nr. 31. 9 Karrierefehler, die jeder Entwickler vermeiden sollte. Warum erfreut sich die REST-API-Architektur zunehmender Beliebtheit?

9 Karrierefehler, die jeder Softwareentwickler vermeiden sollte

Quelle: Infoworld Seien wir ehrlich. Einige von Ihnen haben angefangen, Programmieren zu lernen, weil Sie oder Ihre Eltern dachten, dass es für Sie einfacher wäre, viel Geld zu verdienen. Du hast dich in der Schule nicht wirklich für Computer interessiert und die Softwareentwicklung hat dir nicht wirklich Spaß gemacht. Wenn dies zutrifft, bedeutet dies, dass Sie immer ein mittelmäßiger Programmierer sein werden. Ja, Sie werden gutes Geld verdienen, weil unsere Branche es bevorzugt, aber dieser Artikel ist nichts für Sie. Aber wenn Sie als Kind dafür bestraft wurden, dass Sie elektronische Geräte auseinandergenommen haben, um herauszufinden, wie sie funktionieren ... Wenn Sie die halbe Nacht im Internet verbracht haben, um zu lernen, wie man ein Videospiel erstellt ... Wenn Sie wertvolle Freizeit damit verbracht haben, herauszufinden, was Niemand hat dich gefragt... dieser Artikel ist für dich. Sie müssen die Wahrnehmung Ihrer Karriere ändern. Sie schreiben Code nicht mehr zum Spaß, sondern für Geld. Aus Spaß können Sie Ihre persönlichen Projekte unterstützen. Aber bitte stellen Sie sicher, dass Ihnen zumindest Ihr Job Spaß macht. Wenn nicht, suchen Sie sich nach Möglichkeit einen besseren Ort. Ihr Ziel sollte es sein, Ihren Pensionsfonds zu eröffnen, Ihr gesamtes Geld nach Steuern hineinzustecken, ein Haus und ein Auto zu kaufen und zu tun, was Sie wollen. Vielleicht reisen. Gleichzeitig müssen Sie über Ihre Karriere nachdenken, nicht nur über Ihren aktuellen Job. Dazu müssen Sie neun Fallstricke vermeiden, die wir nun besprechen.

Fallstrick Nr. 1: Bleiben Sie nicht zu lange bei einer Technologie

Ich habe verstanden. Mögen Sie C# oder Java oder JavaScript, Python oder Cobol? Aber die meisten Technologien haben einen Lebenszyklus von Einführung, Höhepunkt, Outsourcing, Nische und Obsoleszenz. Ich meine, wenn Sie Cobol in den 1980er Jahren gekannt hätten, wäre es cool gewesen. Aber Cobol-Programmierer verdienen heutzutage nicht mehr viel Geld. Das heißt, der Punkt ist, dass Sie, wenn Sie nur eine Programmiersprache beherrschen, früher oder später Ihre Ausgaben senken und in eine günstigere Stadt ziehen müssen, weil Sie weniger verdienen.

Fallstrick Nr. 2: Seien Sie kein IT-Monopolist

Sie müssen Ihre Investitionen absichern. Es scheint, als müssten Sie einfach ein Experte für die Technologien werden, die derzeit den Markt dominieren. Aber dann wirst du einer großen Konkurrenz ausgesetzt sein. Wenn die Nachfrage nach Ihrem Fachgebiet zurückgeht, sollten Sie außerdem bereits über einen Ausstiegsplan verfügen. Ich war zum Beispiel ein C++-Freak, als Java herauskam. Ich habe Java gelernt. Vor ein paar Jahren begann jeder über Ruby als den neuen aufstrebenden Stern unter den Programmiersprachen zu reden. Und irgendwann schien es, als würde Perl das gleiche Niveau wie Java erreichen. Die Zukunft vorherzusagen ist schwierig, daher ist die Absicherung Ihrer Wetten der sicherste Weg, um Relevanz auf dem Arbeitsmarkt sicherzustellen.

Falle Nr. 3: Halten Sie nicht an Modeerscheinungen fest

Früher oder später verschwindet die Magie. Die Leute werden keine Groovy- oder Ruby-Entwickler einstellen. Wenn Ihr Chef Ihnen erlaubt, bei einem Projekt ältere Sprachen zu verwenden, liegt das entweder daran, dass es ihm egal ist, oder er ist einfach unwissend. Lernen Sie auf jeden Fall die neueste Technologie kennen und nutzen Sie sie. Seien Sie darauf vorbereitet, einer der Ersten zu sein, der davon erfährt, und ein Experte darin zu werden. Seien Sie andererseits auch auf drastische Änderungen vorbereitet, wenn die Nachfrage nach Ihrem Fachgebiet zurückgeht. Es gibt immer andere neue Technologien, in die man sich verlieben kann, sei es eine Sprache oder eine Datenbank.

Falle Nr. 4: Allergie gegen Regeln

Jede Organisation, egal wie groß oder klein, hat ihre eigenen Büroregeln. Sie müssen sie studieren und ihnen folgen. Andernfalls werden Sie zum Spielball eines anderen oder finden sich isoliert im Team wieder. Wenn Sie an einer Karriere und produktiven Beziehungen am Arbeitsplatz interessiert sind, lernen Sie, defensive Taktiken in den Büroregeln zu befolgen .

Falle Nr. 5: Desinteresse am Geschäft

„Ich bin nur ein Entwickler, ich interessiere mich nicht für das Geschäft.“ Das ist ein Weg ins Nirgendwo. Sie müssen lernen zu zählen. Geht es Ihrem Unternehmen gut? Was sind die wichtigsten Geschäftsziele? Was sind ihre wichtigsten Projekte? Wie helfen Technologie oder Software dabei, diese Ziele zu erreichen? Wie passt Ihr Unternehmen in die Gesamtbranche? Wenn Sie die Antworten auf diese Fragen nicht kennen, werden Sie am Ende für einen relativ unbedeutenden Geldbetrag an unwichtigen Projekten für unwichtige Leute in unwichtigen Unternehmen arbeiten.

Fallstrick Nr. 6: Die Mentalität der „gewerkschaftlichen Solidarität“

Als ich jung war, war einer meiner Kollegen ein Mann, der fast alles sechs Monate im Voraus plante. Er machte den Fehler, in den Urlaub zu fahren, also beendete ich das gesamte Projekt in zwei Wochen, ließ ihm aber ein Teil übrig, an dem er arbeiten konnte. Ich hatte erwartet, dass er sich darüber freuen würde. Es stellte sich heraus, dass er nicht glücklich war. Es endete damit, dass er jede Gelegenheit nutzte, um mich zu feuern. Dies wurde sein Hauptziel. Er beschwerte sich sogar bei unserem neuen Direktor über mich. Natürlich habe ich meine ganze Arbeit erledigt. Ich war ein Innovator. Ich habe immer neue Wege gefunden, Dinge besser und schneller zu machen und Probleme zu lösen. Er ging in den Ruhestand, kurz nachdem ich zu einem anderen Job gegangen war. Mehrmals sah ich ihn in einem Café und wir taten so, als würden wir uns nicht kennen. Dies wäre nicht das letzte Mal, dass ich auf diese Art von Arbeit gestoßen bin: „Machen Sie die Dinge langsam, sonst wird es noch schlimmer.“ Mein Rat: Schreiben Sie korrekten Code, aber seien Sie auf das Unerwartete vorbereitet. Lässt sich das Problem nicht lösen, lassen Sie die Tür zuschlagen: Ihr Unternehmen ist nicht das einzige auf dem Markt.

Fallstrick Nr. 7: Sie kennen Ihren Wert nicht

„Ich bin nicht wegen des Geldes hier.“ Na dann, nimm dir ein Hobby. Gehen Sie nicht jeden Tag zur Arbeit und denken Sie über Ihren nächsten Gehaltsscheck nach. Sie sollten auch nicht zur Arbeit gehen, wenn Sie 50 % weniger verdienen als alle anderen. Erkenne deinen Wert und unterschätze ihn nicht.

Falle Nr. 8: Behandeln Sie Ihren Job wie einen Job

„Es ist nur ein Job.“ Nein, das ist ein Schritt in Ihrer Karriere. Du wirst nicht ewig in diesem Job bleiben. Was können Sie hier also lernen? Was wird Ihr nächster Schritt sein? Wo möchten Sie letztendlich landen? Wie wird Ihnen diese Arbeit dabei helfen, dieses Ziel zu erreichen? Steigern Sie Ihr Bewusstsein für Ihre Umgebung. Dies wird Ihnen auf lange Sicht gute Dienste leisten. Es ist nicht nur ein Job, es ist eine Reise.

Fallstrick Nr. 9: Sie denken, es geht nur um Geld

Verkäufer sagen gerne: „Ich arbeite, wenn man eine Münze wirft.“ Ja, aber wenn Sie nicht im Vertrieb arbeiten, möchte niemand mit jemandem zusammenarbeiten, der diesen Job nur des Geldes wegen ausübt. Ich weiß, dass ich nur mit jemandem zusammenarbeiten möchte, der für seine Arbeit verantwortlich ist. Und Sie? Andererseits besteht kein Grund, unerträgliche Verantwortung zu übernehmen. Wenn Sie sich wirklich nur um die ewige Debatte über Tabs oder Lücken sorgen, müssen Sie möglicherweise ein Beruhigungsmittel einnehmen.

Warum erfreut sich die REST-API-Architektur zunehmender Beliebtheit?

Quelle: DZone Sofortige Kommunikation ist eine erstaunliche Sache. Wir sind alle daran gewöhnt, dass wir sofort mit jedem Ort der Welt kommunizieren können. Von Desktop-Computern oder Mobilgeräten aus können wir überall und überall alles kaufen, veröffentlichen, anhängen und auswählen. Wir sind miteinander und mit der Welt verbunden wie nie zuvor. Aber wie passiert das? Wie gelangen Daten „von dort“ zu uns? Geräte und Anwendungen kommunizieren über eine Anwendungsprogrammierschnittstelle (API) miteinander. Das ist genau der Motor „unter der Haube“. Es geschieht immer hinter den Kulissen und wir neigen dazu, es als etwas Gewöhnliches zu betrachten, aber es ist die API, die all die Interaktivität schafft, auf die wir zählen.

Was ist eine API?

Einfach ausgedrückt ist eine API ein Messenger, der Anfragen entgegennimmt, dem System mitteilt, was Sie tun möchten, und dann eine Antwort an Sie zurücksendet. Stellen Sie sich als visuelles Beispiel die API als Kellner in einem Restaurant vor. Stellen Sie sich vor, Sie sitzen an einem Tisch, halten eine Speisekarte in Ihren Händen und die Küche ist Teil des Systems, das Ihre Bestellung zubereitet. Die API ist der Link, der Ihre Bestellung an die Küche übermittelt und das Essen an den Tisch liefert.

Nehmen wir ein reales Beispiel:

Wir alle sind mit der Online-Suche nach Flügen vertraut und wissen, dass wir für die Buchung eines Fluges mit der Website der Fluggesellschaft interagieren müssen. Sie greifen auf deren Datenbank zu, um zu sehen, ob an einem bestimmten Datum Sitzplätze verfügbar sind und mit welchen Kosten Sie aufgrund Ihrer Fluganforderungen rechnen können. Aber was ist, wenn Sie keine Website einer Fluggesellschaft nutzen, die direkten Zugriff auf Informationen hat? Was wäre, wenn Sie einen Online-Buchungsdienst nutzen, der Informationen von verschiedenen Fluggesellschaften sammelt? Der Dienst interagiert mit der API der Fluggesellschaft, wobei die API die Schnittstelle ist, die, wie unser hilfsbereiter Kellner, vom Onlinedienst Informationen über Sitzplatzreservierungen und die vom Passagier gewählten Essens- oder Gepäckpräferenzen anfordert. Die API nimmt dann die Antwort der Fluggesellschaft auf und übermittelt sie zurück an den Onlinedienst, der die Informationen dem Passagier anzeigt. Bei allen anderen Anwendungen, Daten und Geräten findet nahezu der gleiche Prozess statt. Sie alle verfügen über APIs, die es Computern ermöglichen, sie zu steuern, und dadurch entsteht letztendlich Kommunikation.

Welche Arten von APIs gibt es?

Die API-Architektur kann im Wesentlichen auf zwei Arten implementiert werden: Eine dieser Methoden zur Implementierung der Informationsübertragung ist SOAP und die andere Methode ist REST. Wir haben bereits festgestellt, dass APIs die Kommunikation zwischen zwei Anwendungen ermöglichen. Jetzt erfahren wir, wie genau SOAP und REST in die Kommunikationsarchitektur passen.

SOAP-API

SOAP (Simple Object Access Protocol) ist ein Webdienst, der Spezifikationen mit bestimmten Kommunikationsprinzipien folgt, die zwischen einer zentralen Stelle namens W3C und einem Kernsatz von Spezifikationen festgelegt werden. Dieses Set beinhaltet:

• SEIFE
• WSDL
• UDDI

SOAP ist ein Protokoll, das definiert, wie zwei Anwendungen miteinander kommunizieren. Zwei Anwendungen müssen bei der Kommunikation miteinander einem gemeinsamen Format folgen, und dieses gemeinsame Format muss auf der XML-Sprache basieren. Das XML in SOAP-APIs muss dem SOAP-Nachrichtenstandard entsprechen, der aus Umschlag, Header und Text besteht.

REST-API

Dies ist ein sehr wichtiges, aber oft missverstandenes Konzept von Webdiensten. Lassen Sie uns also entschlüsseln, was REST oder RESTful API bedeutet. REST ist ein Webdienst, der mithilfe eigener Architekturprinzipien die Kommunikation zwischen zwei Anwendungen initiiert. REST-Architektur ist ein Architekturstil, der keinem Protokoll folgt, es gibt keine strengen Spezifikationen und es gibt keine zentrale Autorität, die die Spezifikationen kontrolliert. Dies macht REST vielseitig für die Nutzung oder Erstellung jeglicher Art von Diensten. Wenn diese Prinzipien beim Erstellen eines Webdienstes angewendet werden, erhalten wir einen RESTful-Webdienst. Lassen Sie uns nun etwas tiefer gehen und die Prinzipien herausfinden, auf denen die REST-Architektur basiert.

Einheitliche Schnittstelle

In einer RESTful-Architektur kann alles als Ressource betrachtet werden. Wenn Sie beispielsweise versuchen, eine Anwendung für ein Mitarbeiterverwaltungssystem zu erstellen. Diese Anwendung kann in jeder Sprache, auf jeder Plattform und für jede Plattform entwickelt werden. Ebenso kann jede Datenbank zur Abwicklung interner Dienste genutzt werden. Das Konzept der Ressourcen in der REST-API impliziert, dass der Benutzer jede Information oder jedes Modul als Ressource definieren kann. Bei einem Mitarbeiterverwaltungssystem kann der Ersteller die Mitarbeiterressourcen, Abteilungen und alle anderen in der Anwendung verwendeten Module definieren.

Staatenlos

In einer RESTful-Architektur sind alle Antworten und Anfragen sowie die gesamte Kommunikation zwischen Servern zustandslos. Dies bedeutet, dass der Server den aktuellen Status des Systems nicht aufrechterhält und der Client möglicherweise eine Anfrage sendet, die er selbst ausführt. Und diese Anfrage hängt nicht von einer der vorherigen Anfragen ab. Wenn Sie beispielsweise online einkaufen und Artikel in Ihren Warenkorb legen, speichert der Server den Status Ihres Warenkorbs nicht. Daher wird jedes Mal, wenn ein Benutzer eine Anfrage an den Server sendet, der Status des Warenkorbs zum Zeitpunkt des Kaufs angezeigt Anfrage wurde gestellt. Im zustandslosen Zustand entsteht für den Server kein Overhead zum Speichern oder Verwalten der Sitzung, wodurch die Leistung des Webdienstes verbessert wird.

Caching-Fähigkeit

Im letzten Protokoll haben wir festgestellt, dass in der RESTful-Architektur der Server den Sitzungsstatus nicht speichert, sondern das gesamte Caching auf der Clientseite erfolgt. Immer wenn ein Client eine Anfrage an den Server sendet, gibt der Server eine Antwort zurück, die die tatsächlichen Daten sowie andere Metadaten enthält, die dem Client mitteilen, ob er die Antwort lokal speichern soll oder nicht.

Mehrstufiges System

REST-Prinzipien besagen, dass bei jeder Kommunikation zwischen einem Client und einem Server mehrere Schichten zwischen ihnen vorhanden sein können und diese Schichten zur Implementierung mehrerer Zwecke wie Nachrichtenübersetzung, Leistungsverbesserung, Caching und einer Vielzahl anderer Dinge verwendet werden können. Jede Kommunikationsebene hat eine bestimmte Aufgabe. Mit mehreren Kommunikationsebenen arbeitet das System effizient und verbessert Geschwindigkeit und Haltbarkeit.

Code auf Anfrage

Dies ist eine optionale Einschränkung von RESTful-Webdiensten, die funktioniert, wenn der Benutzer eine Anfrage zum Erhalt einer Antwort sendet. Die Antwort kann clientseitigen Code ausführen. Dieses Prinzip erweitert die Funktionalität der Kommunikation.

Warum werden REST-APIs immer häufiger verwendet?

REST ist größtenteils einfacher zu verwenden, flexibler und bietet gegenüber SOAP eine Reihe von Vorteilen. Sie benötigen beispielsweise keine teuren Tools, um mit einem Webdienst zu interagieren. Die REST-Architektur ist einfacher, lässt sich leicht anpassen und erfordert keine besonderen Kenntnisse beim Erstellen eines Kommunikationsmodells. Die Verwendung ist effizient, da die Clientseite des Servers zum Speichern clientbezogener Informationen verwendet werden kann. REST verwendet kleinere Nachrichtenformate und ermöglicht schnellere Interaktionen, da keine zeitaufwändige Verarbeitung erforderlich ist. Auch in der Designphilosophie ist REST anderen Webtechnologien näher.

SEIFE oder REST?

Für die Anforderungen einer typischen Webanwendung ist SOAP oft übertrieben. REST ist eine einfachere Lösung, die alles bietet, was Sie brauchen, wenn eine Webanwendung eine API benötigt. Es gibt jedoch Zeiten, in denen die API etwas komplexer sein muss, um Aufgaben zu erfüllen. Wenn beispielsweise eine API für automatisierte Anfragen erforderlich ist, wäre eine SOAP-API für dieses Szenario die bessere Wahl. Einfach ausgedrückt: Wählen Sie SOAP, wenn das Problem groß und komplex ist, und wählen Sie REST, wenn Sie eine einfache Lösung benötigen.