Przerwa kawowa #31. 9 błędów zawodowych, których powinien unikać każdy programista Dlaczego architektura REST API zyskuje na popularności?

9 błędów zawodowych, których powinien unikać każdy programista

Źródło: Infoworld Bądźmy szczerzy. Niektórzy z Was zaczęli uczyć się programowania, ponieważ Ty lub Twoi rodzice myśleliście, że łatwiej będzie wam zarobić dużo pieniędzy. W szkole nie interesowałeś się komputerami i nie podobało ci się tworzenie oprogramowania. Jeśli to prawda, oznacza to, że zawsze będziesz przeciętnym programistą. Tak, zarobisz dobre pieniądze, bo nasza branża to faworyzuje, ale ten artykuł nie jest dla Ciebie. Ale jeśli jako dziecko zostałeś ukarany za rozbieranie elektroniki, aby dowiedzieć się, jak ona działa... Jeśli spędziłeś pół nocy w Internecie, aby dowiedzieć się, jak stworzyć grę wideo... Jeśli spędziłeś cenny wolny czas na nauce tego, co nikt Cię nie pytał... ten artykuł jest dla Ciebie. Musisz zmienić postrzeganie swojej kariery. Nie piszesz już kodu dla zabawy: robisz to dla pieniędzy. Dla zabawy możesz wspierać swoje osobiste projekty. Ale upewnij się, że przynajmniej lubisz swoją codzienną pracę. Jeśli nie, znajdź lepsze miejsce, jeśli to możliwe. Twoim celem powinno być otwarcie funduszu emerytalnego, włożenie w niego wszystkich dolarów po opodatkowaniu, zakup domu, samochodu i robienie, co chcesz. Może podróż. Jednocześnie musisz myśleć o swojej karierze, a nie tylko o swojej obecnej pracy. Aby to zrobić, musisz uniknąć dziewięciu pułapek, które teraz omówimy.

Pułapka nr 1: Nie pozostawaj zbyt długo w jednej technologii

Rozumiem. Lubisz C#, Javę, JavaScript, Python lub Cobol? Jednak większość technologii ma cykl życia obejmujący przyjęcie, szczyt, outsourcing, niszę i starzenie się. To znaczy, gdybyś znał Cobola w latach 80., byłoby fajnie. Ale programiści Cobola obecnie nie zarabiają dużo pieniędzy. Czyli chodzi o to, że znając tylko jeden język programowania, prędzej czy później trzeba będzie ciąć wydatki, przeprowadzić się do tańszego miasta, bo mniej zarobisz.

Pułapka nr 2: nie bądź monopolistą IT

Musisz zabezpieczyć swoje inwestycje. Może się wydawać, że wystarczy zostać ekspertem w zakresie technologii, które obecnie dominują na rynku. Ale wtedy będziesz musiał stawić czoła dużej konkurencji. Ponadto, gdy popyt na Twoją specjalizację spada, powinieneś już mieć gotowy plan wyjścia. Na przykład byłem maniakiem C++, kiedy pojawiła się Java. Nauczyłem się Javy. Kilka lat temu wszyscy zaczęli mówić o Ruby jako o nowej wschodzącej gwieździe wśród języków programowania. I w pewnym momencie wydawało się, że Perl osiągnie ten sam poziom co Java. Przewidywanie przyszłości jest trudne, dlatego zabezpieczanie zakładów jest najbezpieczniejszym sposobem zapewnienia sobie znaczenia na rynku pracy.

Pułapka nr 3: Nie kieruj się modą

Prędzej czy później magia zniknie. Ludzie nie będą zatrudniać programistów Groovy ani Ruby. Jeśli Twój szef pozwala Ci używać w projekcie starszych języków, będzie to albo dlatego, że go to nie obchodzi, albo po prostu jest ignorantem. Oczywiście ucz się i korzystaj z najnowszych technologii. Bądź przygotowany na to, że dowiesz się o nich jako jeden z pierwszych i zostaniesz w tym ekspertem. Z drugiej strony bądź także przygotowany na wprowadzenie drastycznych zmian, jeśli popyt na Twoją specjalizację spadnie. Zawsze są inne nowe technologie, w których można się zakochać, czy to język, czy baza danych.

Pułapka nr 4: Alergia na zasady

Każda organizacja, niezależnie od tego, czy jest duża, czy mała, ma swoje własne zasady dotyczące biura. Będziesz musiał je przestudiować i podążać za nimi. W przeciwnym razie staniesz się pionkiem w czyjejś grze lub zostaniesz odizolowany w drużynie. Jeśli interesuje Cię kariera i produktywne relacje w pracy, naucz się stosować taktykę defensywną zawartą w zasadach biurowych.

Pułapka nr 5: brak zainteresowania biznesem

„Jestem tylko programistą, nie interesuje mnie biznes”. To jest droga donikąd. Musisz nauczyć się liczyć. Czy Twoja firma radzi sobie dobrze? Jakie są jej główne cele biznesowe? Jakie są jej najważniejsze projekty? W jaki sposób technologia lub oprogramowanie pomaga je osiągnąć? Jak Twoja firma wpisuje się w całą branżę? Jeśli nie znasz odpowiedzi na te pytania, skończysz na pracy nad nieistotnymi projektami dla nieważnych ludzi w nieistotnych firmach za stosunkowo niewielką sumę pieniędzy.

Pułapka nr 6: mentalność „solidarności związkowej”

Kiedy byłem młody, jeden z moich kolegów był człowiekiem, który planował prawie wszystko z sześciomiesięcznym wyprzedzeniem. Popełnił błąd, wyjeżdżając na wakacje, więc skończyłem cały projekt w dwa tygodnie, ale zostawiłem mu jedną część do pracy. Spodziewałam się, że będzie z tego powodu szczęśliwy. Okazało się, że nie był zadowolony. Wszystko skończyło się tym, że wykorzystywał każdą okazję, żeby mnie zwolnić. To stało się jego głównym celem. Nawet poskarżył się na mnie naszemu nowemu dyrektorowi. Oczywiście wykonałem całą swoją pracę. Byłem innowatorem. Zawsze poszukiwałem nowych sposobów, aby robić rzeczy lepiej i szybciej oraz rozwiązywać problemy. Odszedł na emeryturę wkrótce po moim odejściu do innej pracy. Kilka razy widziałam go w kawiarni i udawaliśmy, że się nie znamy. To nie byłby ostatni raz, kiedy spotkałem się z tego typu pracą: „Rób wszystko powoli, bo inaczej sytuacja się pogorszy.” Moja rada: napisz poprawny kod, ale bądź przygotowany na nieoczekiwane. Jeśli problemu nie da się rozwiązać, zostaw trzaskanie drzwiami: Twoja firma nie jest jedyna na rynku.

Pułapka nr 7: nie znasz swojej wartości

„Nie jestem tu dla pieniędzy”. No to zajmij się jakimś hobby. Nie idź codziennie do pracy, myśląc o następnej wypłacie. Nie powinieneś także chodzić do pracy, jeśli zarabiasz o 50% mniej niż wszyscy inni. Znaj swoją wartość i nie lekceważ jej.

Pułapka nr 8: Traktuj swoją pracę jak pracę

„To tylko praca”. Nie, to krok w Twojej karierze. Nie będziesz w tej pracy wiecznie. Czego więc możesz się tutaj nauczyć? Jaki będzie Twój następny krok? Gdzie ostatecznie chcesz dotrzeć? W jaki sposób ta praca pomoże Ci osiągnąć ten cel? Zwiększ swoją świadomość otoczenia. To będzie Ci dobrze służyć na dłuższą metę. To nie tylko praca, to podróż.

Pułapka nr 9: Myślisz, że chodzi tylko o pieniądze

Sprzedawcy lubią mawiać: „Pracuję, jeśli rzucisz monetą”. Tak, ale jeśli nie pracujesz w sprzedaży, nikt nie chce pracować z kimś, kto wykonuje tę pracę tylko dla pieniędzy. Wiem, że chcę pracować tylko z kimś, kto jest odpowiedzialny za swoją pracę. A ty? Z drugiej strony nie ma potrzeby być nieznośnie odpowiedzialnym. Jeśli naprawdę martwisz się tylko wieczną debatą na temat zakładek lub luk, być może będziesz musiał zażyć środek uspokajający.

Dlaczego architektura REST API zyskuje na popularności?

Źródło: DZone Natychmiastowa komunikacja to niesamowita rzecz. Wszyscy jesteśmy przyzwyczajeni do tego, że możemy błyskawicznie porozumieć się z każdym miejscem na świecie. Z komputerów stacjonarnych lub urządzeń mobilnych możemy kupować, publikować, dołączać i wybierać wszystko, gdziekolwiek. Jesteśmy połączeni ze sobą i ze światem jak nigdy dotąd. Ale jak to się dzieje? W jaki sposób dane docierają do nas „stamtąd”? Urządzenia i aplikacje komunikują się ze sobą za pomocą interfejsu programowania aplikacji, czyli API. To jest dokładnie silnik „pod maską”. Zawsze dzieje się to za kulisami i zwykle myślimy o tym jak o czymś zwyczajnym, ale to interfejs API tworzy całą interaktywność, na którą liczymy.

Co to jest interfejs API?

Mówiąc najprościej, API to komunikator, który przyjmuje żądania, mówi systemowi, co chcesz zrobić, a następnie zwraca Ci odpowiedź. Dla wizualnego przykładu wyobraźmy sobie API jako kelnera w restauracji. Wyobraź sobie, że siedzisz przy stole, trzymając w rękach menu, a kuchnia jest częścią systemu, który przygotuje Twoje zamówienie. API to link, który przekaże Twoje zamówienie do kuchni i dostarczy jedzenie na stół.

Weźmy prawdziwy przykład:

Wszyscy znamy proces wyszukiwania lotów w Internecie i wiemy, że aby zarezerwować lot, będziemy musieli wejść w interakcję ze stroną internetową linii lotniczej. Uzyskujesz dostęp do ich bazy danych, aby sprawdzić, czy miejsca są dostępne w określonym terminie i jakich kosztów możesz się spodziewać w zależności od wymagań dotyczących lotu. Co jednak, jeśli nie korzystasz ze strony internetowej linii lotniczej, która ma bezpośredni dostęp do informacji? Co się stanie, jeśli skorzystasz z usługi rezerwacji online, która zbiera informacje od różnych linii lotniczych? Usługa współdziała z interfejsem API linii lotniczej, gdzie interfejs API jest interfejsem, który podobnie jak nasz pomocny kelner żąda od serwisu internetowego informacji na temat rezerwacji miejsc oraz preferencji pasażera dotyczących posiłku lub bagażu. Następnie interfejs API pobiera odpowiedź linii lotniczej i dostarcza ją z powrotem do usługi online, która wyświetla informacje pasażerowi. Prawie ten sam proces zachodzi pomiędzy wszystkimi innymi aplikacjami, danymi i urządzeniami. Wszystkie mają interfejsy API, które umożliwiają komputerom kontrolowanie ich, co ostatecznie tworzy komunikację.

Jakie są rodzaje interfejsów API?

Architekturę API można zaimplementować na dwa główne sposoby: jednym z tych sposobów implementacji przesyłania informacji jest SOAP, a drugim głównym sposobem jest REST. Ustaliliśmy już, że interfejsy API zapewniają komunikację pomiędzy dwiema aplikacjami. Teraz dowiemy się jak dokładnie SOAP i REST wpasowują się w architekturę komunikacyjną.

API SOAP

SOAP (Simple Object Access Protocol) to usługa sieciowa zgodna ze specyfikacjami i pewnymi zasadami komunikacji ustalonymi pomiędzy organem centralnym zwanym W3C a podstawowym zestawem specyfikacji. Ten zestaw zawiera:

• MYDŁO
• WSDL
• UDDI

SOAP to protokół definiujący sposób, w jaki dwie aplikacje będą się ze sobą komunikować. Podczas wzajemnej komunikacji dwie aplikacje muszą mieć wspólny format, a ten wspólny format musi być oparty na języku XML. Plik XML w interfejsach API SOAP musi być zgodny ze standardem komunikatów SOAP, który składa się z koperty, nagłówka i treści.

API RESTOWE

To bardzo ważna, ale często źle rozumiana koncepcja usług sieciowych, dlatego rozszyfrujmy, co oznacza REST, czyli RESTful API. REST to usługa internetowa, która inicjuje komunikację pomiędzy dwiema aplikacjami przy użyciu własnych zasad architektury. Architektura REST to styl architektoniczny, który nie jest zgodny z żadnym protokołem, nie ma ścisłych specyfikacji i nie ma centralnego organu kontrolującego specyfikacje. Dzięki temu REST jest wszechstronny w użyciu lub tworzeniu dowolnego rodzaju usług. Kiedy te zasady zostaną zastosowane podczas tworzenia usługi internetowej, otrzymamy usługę sieciową RESTful. Teraz zejdźmy trochę głębiej i poznajmy zasady, na których opiera się architektura REST.

Ujednolicony interfejs

W architekturze RESTful wszystko można uznać za zasób. Na przykład, jeśli próbujesz stworzyć aplikację dla systemu zarządzania pracownikami. Tę aplikację można opracować w dowolnym języku, na dowolnej platformie i dla dowolnej platformy. Podobnie dowolna baza danych może być używana do obsługi usług wewnętrznych. Koncepcja zasobów w REST API zakłada, że ​​użytkownik może zdefiniować dowolną informację lub dowolny moduł jako zasób. Mając system zarządzania pracownikami, twórca ma możliwość zdefiniowania zasobu pracowników, działów i dowolnego innego modułu wykorzystywanego w aplikacji.

Bezpaństwowiec

W architekturze RESTful wszystkie odpowiedzi i żądania oraz cała komunikacja między serwerami są bezstanowe. Oznacza to, że serwer nie utrzymuje aktualnego stanu systemu, klient może wysłać żądanie, które samo się realizuje. I to żądanie nie zależy od żadnego z poprzednich żądań. Na przykład, jeśli robisz zakupy online i dodajesz produkty do koszyka, serwer nie będzie śledził stanu Twojego koszyka, więc za każdym razem, gdy użytkownik prześle żądanie do serwera, będzie on zawierał stan koszyka w momencie złożono wniosek. W przypadku bezstanowości serwer nie ponosi żadnych kosztów związanych z przechowywaniem lub utrzymywaniem sesji, co poprawia wydajność usługi internetowej.

Możliwość buforowania

W ostatnim protokole zauważyliśmy, że w architekturze RESTful serwer nie zapisuje stanu sesji, całe buforowanie odbywa się po stronie klienta. Ilekroć klient wysyła żądanie do serwera, serwer zwraca odpowiedź zawierającą rzeczywiste dane, a także inne metadane, które informują klienta, czy powinien przechowywać odpowiedź lokalnie, czy nie.

System wielopoziomowy

Zasady REST stanowią, że ilekroć istnieje komunikacja między klientem a serwerem, może istnieć między nimi wiele warstw, które można wykorzystać do realizacji wielu celów, takich jak tłumaczenie wiadomości, zwiększanie wydajności, buforowanie i wiele innych rzeczy. Każdy poziom komunikacji ma określone zadanie. Dzięki wielu warstwom komunikacji system działa wydajnie, poprawiając szybkość i trwałość.

Kod na żądanie

Jest to opcjonalne ograniczenie usług internetowych RESTful, które działa, gdy użytkownik przesyła żądanie otrzymania odpowiedzi. Odpowiedź może uruchomić kod po stronie klienta. Zasada ta rozszerza funkcjonalność komunikacji.

Dlaczego coraz częściej wykorzystywane są API REST?

REST jest w większości łatwiejszy w użyciu, bardziej elastyczny i ma wiele zalet w porównaniu z SOAP. Na przykład nie potrzebujesz drogich narzędzi do interakcji z dowolną usługą internetową. Architektura REST jest prostsza, można ją łatwo dostosować i nie wymaga specjalnych umiejętności przy tworzeniu modelu komunikacji. Jest wydajny w użyciu, ponieważ może wykorzystywać stronę klienta serwera do przechowywania informacji związanych z klientem. REST wykorzystuje mniejsze formaty wiadomości i zapewnia szybsze interakcje, ponieważ nie wymaga czasochłonnego przetwarzania. REST jest także bliższy innym technologiom internetowym, jeśli chodzi o filozofię projektowania.

MYDŁO czy ODPOCZYNEK?

W przypadku wymagań typowej aplikacji internetowej SOAP jest często przesadą. REST to prostsze rozwiązanie, które ma wszystko, czego potrzebujesz, gdy aplikacja internetowa potrzebuje API. Są jednak chwile, kiedy interfejs API musi być nieco bardziej złożony, aby wykonać zadania. Na przykład, jeśli do automatycznych żądań wymagany jest interfejs API, w tym scenariuszu lepszym wyborem będzie interfejs API protokołu SOAP. Mówiąc najprościej, wybierz SOAP, jeśli problem jest duży i złożony, i wybierz REST, jeśli potrzebujesz prostego rozwiązania.