Rehat kopi #31. 9 kesilapan kerjaya yang harus dielakkan oleh setiap pembangun. Mengapakah seni bina REST API semakin popular?

9 Kesilapan Kerjaya Setiap Pembangun Perisian Patut Elakkan

Sumber: Infoworld Sejujurnya. Sesetengah daripada anda mula belajar pengaturcaraan kerana anda atau ibu bapa anda berpendapat lebih mudah untuk anda menjana wang yang banyak. Anda tidak begitu menyukai komputer di sekolah, dan anda tidak begitu menikmati pembangunan perisian. Jika ini benar, ini bermakna anda akan sentiasa menjadi pengaturcara yang biasa-biasa sahaja. Ya, anda akan memperoleh wang yang lumayan kerana industri kami menyukainya, tetapi artikel ini bukan untuk anda. Tetapi jika anda dihukum sebagai seorang kanak-kanak kerana mengasingkan elektronik untuk mengetahui cara ia berfungsi... Jika anda menghabiskan separuh malam di Internet untuk belajar cara mencipta permainan video... Jika anda menghabiskan masa lapang yang berharga untuk belajar tentang apa tiada siapa yang bertanya kepada anda... artikel ini adalah untuk anda. Anda perlu mengubah persepsi kerjaya anda. Anda tidak lagi menulis kod untuk keseronokan: anda melakukannya untuk wang. Untuk keseronokan, anda boleh menyokong projek peribadi anda. Tetapi sila pastikan anda sekurang-kurangnya menikmati pekerjaan harian anda. Jika tidak, cari tempat yang lebih baik jika boleh. Matlamat anda adalah untuk membuka dana persaraan anda, meletakkan semua wang selepas cukai anda ke dalamnya, membeli rumah, kereta dan melakukan apa yang anda mahu. Mungkin melancong. Pada masa yang sama, anda perlu memikirkan tentang kerjaya anda, bukan hanya pekerjaan anda sekarang. Untuk melakukan ini, anda perlu mengelakkan sembilan perangkap, yang kini akan kita bincangkan.

Perangkap #1: Jangan kekal dalam satu teknologi terlalu lama

Saya faham. Adakah anda suka C# atau Java atau JavaScript, Python atau Cobol. Tetapi kebanyakan teknologi mempunyai kitaran hayat penerimaan, kemuncak, penyumberan luar, niche dan usang. Maksud saya, jika anda mengenali Cobol pada tahun 1980-an, ia pasti hebat. Tetapi pengaturcara Cobol tidak membuat banyak wang hari ini. Iaitu, maksudnya ialah mengetahui hanya satu bahasa pengaturcaraan, lambat laun anda perlu mengurangkan perbelanjaan anda, berpindah ke bandar yang lebih murah, kerana anda akan mendapat lebih sedikit.

Perangkap No. 2: jangan jadi monopoli IT

Anda perlu melindung nilai pelaburan anda. Nampaknya anda hanya perlu menjadi pakar dalam teknologi yang kini menguasai pasaran. Tetapi kemudian anda akan menghadapi banyak persaingan. Selain itu, apabila permintaan untuk kepakaran anda menurun, anda sepatutnya sudah mempunyai pelan keluar. Sebagai contoh, saya seorang geek C++ apabila Java keluar. Saya belajar Java. Beberapa tahun yang lalu, semua orang mula bercakap tentang Ruby sebagai bintang baharu yang semakin meningkat dalam kalangan bahasa pengaturcaraan. Dan pada satu ketika nampaknya Perl akan mencapai tahap yang sama seperti Java. Meramalkan masa depan adalah sukar, jadi melindung nilai pertaruhan anda adalah cara paling selamat untuk memastikan perkaitan dalam pasaran kerja.

Perangkap #3: Jangan berpegang pada trend

Cepat atau lambat sihir itu hilang. Orang ramai tidak akan mengupah pembangun Groovy atau Ruby. Jika bos anda membenarkan anda menggunakan bahasa legasi pada projek, itu sama ada kerana dia tidak peduli atau hanya jahil. Dengan segala cara, pelajari dan gunakan teknologi terkini. Bersedia untuk menjadi salah seorang yang pertama mengetahui tentang mereka dan menjadi pakar dalam hal itu. Sebaliknya, juga bersedia untuk membuat perubahan drastik jika permintaan untuk kepakaran anda menurun. Sentiasa ada teknologi baharu lain untuk diminati, sama ada bahasa atau pangkalan data.

Perangkap #4: Alahan kepada peraturan

Setiap organisasi, tidak kira besar atau kecil, mempunyai peraturan pejabatnya sendiri. Anda perlu mempelajarinya dan mengikutinya. Jika tidak, anda akan menjadi bidak dalam permainan orang lain atau mendapati diri anda terasing dalam pasukan. Jika anda berminat dalam kerjaya dan perhubungan yang produktif di tempat kerja, belajar untuk mengikuti taktik pertahanan dalam peraturan pejabat.

Perangkap #5: tidak berminat dalam perniagaan

"Saya hanya pemaju, saya tidak berminat dalam perniagaan." Ini adalah jalan ke mana-mana. Anda perlu belajar mengira. Adakah syarikat anda berjalan dengan baik? Apakah objektif perniagaan utamanya? Apakah projek beliau yang paling penting? Bagaimanakah teknologi atau perisian membantu mencapainya? Bagaimanakah syarikat anda sesuai dengan industri keseluruhan? Jika anda tidak tahu jawapan kepada soalan-soalan ini, anda akhirnya akan bekerja pada projek yang tidak penting untuk orang yang tidak penting di syarikat yang tidak penting dengan jumlah wang yang agak kecil.

Perangkap No. 6: mentaliti "perpaduan kesatuan sekerja"

Semasa saya masih muda, salah seorang rakan sekerja saya adalah seorang lelaki yang merancang hampir semuanya enam bulan lebih awal. Dia membuat kesilapan kerana pergi bercuti, jadi saya menyelesaikan keseluruhan projek dalam masa dua minggu, tetapi meninggalkannya satu bahagian untuk diusahakan. Saya menjangkakan dia akan gembira mengenainya. Ternyata dia tidak berpuas hati. Semuanya berakhir dengan dia menggunakan setiap peluang untuk membuat saya dipecat. Ini menjadi matlamat utamanya. Dia juga mengadu tentang saya kepada pengarah baru kami. Sudah tentu saya melakukan semua kerja saya. Saya adalah seorang inovator. Saya sentiasa mencari cara baharu untuk melakukan sesuatu dengan lebih baik dan lebih pantas serta menyelesaikan masalah. Dia bersara sejurus selepas saya pergi untuk kerja lain. Beberapa kali saya melihatnya di kafe, dan kami berpura-pura tidak mengenali antara satu sama lain. Ini bukan kali terakhir saya menemui jenis kerja ini: "Lakukan perkara perlahan-lahan atau keadaan akan menjadi lebih teruk." Nasihat saya: tulis kod yang betul, tetapi bersedia untuk perkara yang tidak dijangka. Jika masalah itu tidak dapat diselesaikan, tinggalkan menghempas pintu: syarikat anda bukan satu-satunya di pasaran.

Perangkap No. 7: anda tidak tahu nilai anda

"Saya di sini bukan untuk wang." Baiklah, ambil hobi. Jangan pergi kerja setiap hari memikirkan tentang gaji seterusnya. Anda juga tidak sepatutnya pergi bekerja jika anda memperoleh 50% kurang daripada orang lain. Ketahui nilai anda dan jangan meremehkannya.

Perangkap #8: Melayan kerja anda seperti pekerjaan

"Ia hanya satu kerja." Tidak, ini adalah satu langkah dalam kerjaya anda. Anda tidak akan berada dalam pekerjaan ini selama-lamanya. Jadi apa yang anda boleh belajar di sini? Apakah langkah anda seterusnya? Di manakah anda akhirnya mahu berakhir? Bagaimanakah kerja ini akan membantu anda mencapai matlamat itu? Tingkatkan kesedaran anda tentang persekitaran anda. Ini akan memberi manfaat kepada anda dalam jangka masa panjang. Ia bukan sekadar pekerjaan, ia adalah perjalanan.

Perangkap No. 9: Anda fikir ia hanya mengenai wang

Jurujual suka berkata, "Saya bekerja jika anda membelek syiling." Ya, tetapi melainkan anda bekerja dalam bidang jualan, maka tiada siapa yang mahu bekerja dengan seseorang yang berada dalam pekerjaan itu hanya untuk wang. Saya tahu bahawa saya hanya mahu bekerja dengan seseorang yang bertanggungjawab terhadap kerja mereka. Dan kamu? Sebaliknya, tidak perlu bertanggungjawab yang tidak tertanggung. Jika anda benar-benar bimbang tentang perdebatan kekal tab atau jurang, anda mungkin perlu mengambil ubat penenang.

Mengapakah seni bina REST API semakin popular?

Sumber: Komunikasi segera DZone adalah sesuatu yang menakjubkan. Kita semua sudah terbiasa dengan hakikat bahawa kita boleh berkomunikasi dengan serta-merta dengan mana-mana sahaja di dunia. Daripada komputer meja atau peranti mudah alih, kita boleh membeli, menyiarkan, melampirkan dan memilih apa sahaja, di mana-mana sahaja. Kami berhubung antara satu sama lain dan kepada dunia seperti tidak pernah sebelum ini. Tetapi bagaimana ini berlaku? Bagaimanakah data sampai kepada kami "dari sana"? Peranti dan aplikasi berkomunikasi antara satu sama lain menggunakan antara muka pengaturcaraan aplikasi atau API. Ini betul-betul enjin "di bawah hud". Ia sentiasa berada di belakang tabir, dan kami cenderung menganggapnya sebagai sesuatu yang biasa, tetapi APIlah yang mencipta semua interaktiviti yang kami harapkan.

Apakah API?

Ringkasnya, API ialah utusan yang menerima permintaan, memberitahu sistem apa yang anda mahu lakukan dan kemudian mengembalikan respons kepada anda. Untuk contoh visual, bayangkan API sebagai pelayan di restoran. Bayangkan anda sedang duduk di meja, memegang menu di tangan anda, dan dapur adalah sebahagian daripada sistem yang akan menyediakan pesanan anda. API ialah pautan yang akan menghantar pesanan anda ke dapur dan menghantar makanan ke meja.

Mari kita ambil contoh sebenar:

Kita semua sudah biasa dengan proses mencari penerbangan dalam talian dan tahu bahawa untuk menempah penerbangan kita perlu berinteraksi dengan tapak web syarikat penerbangan itu. Anda mengakses pangkalan data mereka untuk melihat sama ada tempat duduk tersedia pada tarikh tertentu dan kos yang boleh anda jangkakan berdasarkan keperluan penerbangan anda. Tetapi bagaimana jika anda tidak menggunakan tapak web syarikat penerbangan yang mempunyai akses terus kepada maklumat? Bagaimana jika anda menggunakan perkhidmatan tempahan dalam talian yang mengumpul maklumat daripada syarikat penerbangan yang berbeza? Perkhidmatan ini berinteraksi dengan API syarikat penerbangan, di mana API adalah antara muka yang, seperti pelayan kami yang membantu, meminta maklumat daripada perkhidmatan dalam talian tentang tempahan tempat duduk dan pilihan makanan atau bagasi pilihan penumpang. API kemudiannya mengambil maklum balas syarikat penerbangan dan menghantarnya kembali kepada perkhidmatan dalam talian, yang memaparkan maklumat kepada penumpang. Proses yang sama berlaku antara semua aplikasi, data dan peranti lain. Mereka semua mempunyai API yang membolehkan komputer mengawalnya, dan ini akhirnya mewujudkan komunikasi.

Apakah jenis API yang ada?

Seni bina API boleh dilaksanakan dalam dua cara utama: salah satu cara melaksanakan pemindahan maklumat ini ialah SOAP, dan cara utama yang lain ialah REST. Kami telah pun menetapkan bahawa API menyediakan komunikasi antara dua aplikasi. Sekarang kita akan belajar bagaimana SOAP dan REST sesuai dengan seni bina komunikasi.

API SABUN

SOAP (Simple Object Access Protocol) ialah perkhidmatan web yang mengikut spesifikasi dengan prinsip komunikasi tertentu yang ditubuhkan antara badan pusat yang dipanggil W3C dan set spesifikasi teras. Set ini termasuk:

• SABUN
• WSDL
• UDDI

SOAP ialah protokol yang mentakrifkan bagaimana dua aplikasi akan berkomunikasi antara satu sama lain. Dua aplikasi mesti mengikut format biasa apabila berkomunikasi antara satu sama lain, dan format biasa ini mesti berdasarkan bahasa XML. XML dalam API SOAP mesti mematuhi standard SOAP Message, yang terdiri daripada Envelop, Header dan Body.

API REST

Ini adalah konsep perkhidmatan web yang sangat penting tetapi sering salah faham, jadi mari kita tafsirkan maksud REST atau RESTful API. REST ialah perkhidmatan web yang memulakan komunikasi antara dua aplikasi menggunakan prinsip seni binanya sendiri. Seni bina REST ialah gaya seni bina yang tidak mengikut sebarang protokol, tiada spesifikasi yang ketat, dan tiada pihak berkuasa pusat yang mengawal spesifikasi. Ini menjadikan REST serba boleh untuk menggunakan atau mencipta sebarang jenis perkhidmatan. Apabila prinsip ini digunakan semasa membuat perkhidmatan web, kami mendapat perkhidmatan web RESTful. Sekarang mari kita mendalami sedikit dan ketahui prinsip yang menjadi asas seni bina REST.

Antara Muka Bersatu

Dalam seni bina RESTful, semuanya boleh dianggap sebagai sumber. Contohnya, jika anda cuba membuat aplikasi untuk sistem pengurusan pekerja. Aplikasi ini boleh dibangunkan menggunakan mana-mana bahasa, pada mana-mana platform dan untuk mana-mana platform. Begitu juga, mana-mana pangkalan data boleh digunakan untuk mengendalikan perkhidmatan dalaman. Konsep sumber dalam REST API membayangkan bahawa pengguna boleh menentukan sebarang maklumat atau mana-mana modul sebagai sumber. Memandangkan sistem pengurusan pekerja, pencipta boleh menentukan sumber pekerja, jabatan dan mana-mana modul lain yang digunakan dalam aplikasi.

Tanpa kewarganegaraan

Dalam seni bina RESTful, semua respons dan permintaan, dan semua komunikasi antara pelayan, adalah tanpa kewarganegaraan. Ini bermakna pelayan tidak mengekalkan keadaan semasa sistem, pelanggan boleh menghantar permintaan yang diselesaikan dengan sendirinya. Dan permintaan ini tidak bergantung pada mana-mana permintaan sebelumnya. Contohnya, jika anda membeli-belah dalam talian dan menambah item pada troli anda, pelayan tidak akan mengekalkan keadaan troli anda, jadi setiap kali pengguna menghantar permintaan kepada pelayan, ia akan mengandungi keadaan troli pada masa permintaan dibuat. Apabila tanpa kewarganegaraan, tiada overhed untuk pelayan menyimpan atau mengekalkan sesi, justeru ia meningkatkan prestasi perkhidmatan web.

Keupayaan caching

Dalam protokol terakhir, kami mendapati bahawa dalam seni bina RESTful pelayan tidak menyimpan keadaan sesi, semua caching berlaku pada bahagian klien. Setiap kali pelanggan menghantar permintaan kepada pelayan, pelayan mengembalikan respons yang mengandungi data sebenar serta metadata lain yang memberitahu klien sama ada ia harus menyimpan respons secara setempat atau tidak.

Sistem pelbagai peringkat

Prinsip REST menyatakan bahawa apabila terdapat komunikasi antara klien dan pelayan, boleh terdapat berbilang lapisan di antara mereka, dan lapisan ini boleh digunakan untuk melaksanakan pelbagai tujuan seperti terjemahan mesej, peningkatan prestasi, caching dan pelbagai perkara lain. Setiap tahap komunikasi mempunyai tugas tertentu. Dengan pelbagai lapisan komunikasi, sistem beroperasi dengan cekap, meningkatkan kelajuan dan ketahanan.

Kod atas permintaan

Ini ialah had pilihan perkhidmatan web RESTful yang berfungsi apabila pengguna menyerahkan permintaan untuk menerima respons. Respons boleh menjalankan kod sisi klien. Prinsip ini memperluaskan fungsi komunikasi.

Mengapakah API REST digunakan dengan lebih kerap?

REST adalah sebahagian besarnya lebih mudah digunakan, lebih fleksibel dan mempunyai beberapa kelebihan berbanding SOAP. Sebagai contoh, anda tidak memerlukan alat yang mahal untuk berinteraksi dengan mana-mana perkhidmatan web. Seni bina REST adalah lebih ringkas, boleh disesuaikan dengan mudah dan tidak memerlukan kemahiran khas semasa mencipta model komunikasi. Ia cekap digunakan kerana ia boleh menggunakan bahagian klien pelayan untuk menyimpan maklumat berkaitan klien. REST menggunakan format mesej yang lebih kecil dan menyediakan interaksi yang lebih pantas kerana ia tidak memerlukan pemprosesan yang memakan masa. REST juga lebih dekat dengan teknologi web lain apabila ia berkaitan dengan falsafah reka bentuk.

SABUN atau REHAT?

Untuk keperluan aplikasi web biasa, SOAP selalunya berlebihan. REST ialah penyelesaian yang lebih mudah yang mempunyai semua yang anda perlukan apabila aplikasi web memerlukan API. Walau bagaimanapun, ada kalanya API perlu sedikit lebih kompleks untuk menyelesaikan tugas. Contohnya, jika API diperlukan untuk permintaan automatik, SOAP API akan menjadi pilihan yang lebih baik untuk senario itu. Ringkasnya, pilih SOAP jika masalahnya besar dan kompleks, dan pilih REST jika anda memerlukan penyelesaian yang mudah.