Nghỉ giải lao #31. 9 sai lầm nghề nghiệp mọi lập trình viên nên tránh Tại sao kiến trúc REST API lại trở nên phổ biến?

9 sai lầm nghề nghiệp mọi nhà phát triển phần mềm nên tránh

Nguồn: Infoworld Hãy thành thật mà nói. Một số bạn bắt đầu học lập trình vì bạn hoặc bố mẹ bạn nghĩ rằng việc kiếm nhiều tiền sẽ dễ dàng hơn. Bạn không thực sự yêu thích máy tính ở trường và bạn không thực sự thích phát triển phần mềm. Nếu điều này đúng thì có nghĩa là bạn sẽ luôn là một lập trình viên tầm thường. Đúng, bạn sẽ kiếm được nhiều tiền vì ngành của chúng tôi ủng hộ điều đó, nhưng bài viết này không dành cho bạn. Nhưng nếu khi còn nhỏ bạn bị trừng phạt vì tội tháo rời các thiết bị điện tử để tìm ra cách chúng hoạt động... Nếu bạn dành nửa đêm trên Internet để học cách tạo ra một trò chơi điện tử... Nếu bạn dành thời gian rảnh rỗi quý báu để học về những gì không ai hỏi bạn... bài viết này là dành cho bạn. Bạn cần thay đổi nhận thức về nghề nghiệp của mình. Bạn không còn viết mã cho vui nữa: bạn làm việc đó vì tiền. Để giải trí, bạn có thể hỗ trợ các dự án cá nhân của mình. Nhưng hãy đảm bảo rằng ít nhất bạn cũng yêu thích công việc hàng ngày của mình. Nếu không, hãy tìm một nơi tốt hơn nếu có thể. Mục tiêu của bạn là mở quỹ hưu trí, dồn tất cả số tiền sau thuế vào đó, mua nhà, xe hơi và làm những gì bạn muốn. Có thể là du lịch. Đồng thời, bạn cần nghĩ đến sự nghiệp của mình chứ không chỉ công việc hiện tại. Để làm được điều này, bạn cần tránh chín cạm bẫy mà chúng ta sẽ thảo luận sau đây.

Cạm bẫy số 1: Đừng sử dụng một công nghệ quá lâu

Tôi hiểu. Bạn thích C# hay Java hay JavaScript, Python hay Cobol. Nhưng hầu hết các công nghệ đều có vòng đời áp dụng, đạt đỉnh cao, gia công phần mềm, thích hợp và lỗi thời. Ý tôi là, nếu bạn biết đến Cobol vào những năm 1980 thì sẽ rất tuyệt. Nhưng các lập trình viên Cobol ngày nay không kiếm được nhiều tiền. Tức là, vấn đề là chỉ biết một ngôn ngữ lập trình, sớm hay muộn bạn sẽ phải cắt giảm chi phí, chuyển đến một thành phố rẻ hơn, vì bạn sẽ kiếm được ít tiền hơn.

Cạm bẫy số 2: Đừng trở thành nhà độc quyền CNTT

Bạn cần phòng ngừa rủi ro cho khoản đầu tư của mình. Có vẻ như bạn chỉ cần trở thành chuyên gia về các công nghệ hiện đang thống trị thị trường. Nhưng sau đó bạn sẽ phải đối mặt với rất nhiều sự cạnh tranh. Ngoài ra, khi nhu cầu về chuyên môn của bạn giảm sút, bạn nên chuẩn bị sẵn kế hoạch rút lui. Ví dụ, tôi là một người đam mê C++ khi Java ra đời. Tôi đã học Java. Một vài năm trước, mọi người bắt đầu nói về Ruby như một ngôi sao mới nổi trong số các ngôn ngữ lập trình. Và đến một lúc nào đó, có vẻ như Perl sẽ đạt đến trình độ tương tự như Java. Dự đoán tương lai là điều khó khăn, vì vậy phòng ngừa rủi ro đặt cược của bạn là cách an toàn nhất để đảm bảo sự phù hợp trong thị trường việc làm.

Cạm bẫy số 3: Đừng chạy theo mốt nhất thời

Sớm hay muộn phép thuật cũng biến mất. Mọi người sẽ không thuê nhà phát triển Groovy hoặc Ruby. Nếu sếp của bạn cho phép bạn sử dụng các ngôn ngữ kế thừa trong một dự án, đó có thể là do ông ấy không quan tâm hoặc đơn giản là không biết gì. Bằng mọi cách, hãy học hỏi và sử dụng công nghệ mới nhất. Hãy chuẩn bị để trở thành một trong những người đầu tiên biết về chúng và trở thành chuyên gia về lĩnh vực đó. Mặt khác, bạn cũng nên chuẩn bị sẵn sàng để thực hiện những thay đổi mạnh mẽ nếu nhu cầu về chuyên môn của bạn giảm sút. Luôn có những công nghệ mới khác để bạn yêu thích, có thể là ngôn ngữ hoặc cơ sở dữ liệu.

Cạm bẫy số 4: Dị ứng với các quy tắc

Mỗi tổ chức dù lớn hay nhỏ đều có những nội quy văn phòng riêng. Bạn sẽ phải nghiên cứu chúng và làm theo chúng. Nếu không, bạn sẽ trở thành con tốt trong trò chơi của người khác hoặc thấy mình bị cô lập trong đội. Nếu bạn quan tâm đến sự nghiệp và các mối quan hệ hiệu quả tại nơi làm việc, hãy học cách tuân theo các chiến thuật phòng thủ trong các quy tắc văn phòng.

Cạm bẫy số 5: không quan tâm đến kinh doanh

"Tôi chỉ là một nhà phát triển, tôi không quan tâm đến kinh doanh." Đây là một con đường dẫn đến hư không. Bạn cần học cách đếm. Công ty của bạn có hoạt động tốt không? Mục tiêu kinh doanh chính của nó là gì? Các dự án quan trọng nhất của cô ấy là gì? Công nghệ hoặc phần mềm giúp đạt được những mục tiêu đó như thế nào? Làm thế nào để công ty của bạn phù hợp với ngành công nghiệp tổng thể? Nếu bạn không biết câu trả lời cho những câu hỏi này, cuối cùng bạn sẽ phải làm những dự án không quan trọng cho những người không quan trọng ở những công ty không quan trọng với số tiền tương đối không đáng kể.

Cạm bẫy số 6: tâm lý “đoàn kết công đoàn”

Khi tôi còn trẻ, một trong những đồng nghiệp của tôi là người luôn lên kế hoạch cho hầu hết mọi việc trước sáu tháng. Anh ấy đã phạm sai lầm khi đi nghỉ, vì vậy tôi đã hoàn thành toàn bộ dự án trong hai tuần nhưng để lại cho anh ấy một phần để làm. Tôi đã mong anh ấy sẽ vui vì điều đó. Thì ra anh không vui. Mọi chuyện kết thúc bằng việc anh ta tận dụng mọi cơ hội để khiến tôi bị sa thải. Đây đã trở thành mục tiêu chính của anh ấy. Anh ấy thậm chí còn phàn nàn về tôi với giám đốc mới của chúng tôi. Tất nhiên là tôi đã làm tất cả công việc của mình. Tôi là một nhà đổi mới. Tôi luôn tìm ra những cách mới để làm mọi việc tốt hơn, nhanh hơn và giải quyết vấn đề. Anh ấy nghỉ hưu ngay sau khi tôi đi làm công việc khác. Nhiều lần tôi gặp anh ấy ở quán cà phê và chúng tôi giả vờ như không quen biết nhau. Đây không phải là lần cuối cùng tôi gặp loại công việc này: "Hãy làm mọi việc thật chậm nếu không mọi việc sẽ trở nên tồi tệ hơn." Lời khuyên của tôi: hãy viết mã đúng, nhưng hãy chuẩn bị cho những điều không mong đợi. Nếu vấn đề không thể giải quyết được, hãy đóng sầm cửa lại: công ty của bạn không phải là công ty duy nhất trên thị trường.

Cạm bẫy số 7: bạn không biết giá trị của mình

"Tôi không ở đây vì tiền." Vậy thì hãy theo đuổi một sở thích. Đừng đi làm mỗi ngày và nghĩ về khoản tiền lương tiếp theo của bạn. Bạn cũng không nên đi làm nếu kiếm được ít hơn 50% so với những người khác. Biết giá trị của bạn và đừng đánh giá thấp nó.

Cạm bẫy số 8: Đối xử với công việc của bạn như một công việc

"Đó chỉ là một công việc thôi." Không, đây là một bước tiến trong sự nghiệp của bạn. Bạn sẽ không làm công việc này mãi mãi. Vậy bạn có thể học được gì ở đây? Bước tiếp theo của bạn sẽ là gì? Cuối cùng bạn muốn kết thúc ở đâu? Công việc này sẽ giúp bạn đạt được mục tiêu đó như thế nào? Tăng nhận thức của bạn về môi trường xung quanh bạn. Điều này sẽ phục vụ bạn tốt về lâu dài. Đó không chỉ là một công việc, đó là một cuộc hành trình.

Cạm bẫy số 9: Bạn nghĩ vấn đề chỉ là tiền

Những người bán hàng thường nói: “Tôi sẽ thành công nếu bạn tung đồng xu”. Đúng, nhưng trừ khi bạn làm việc trong lĩnh vực bán hàng, thì không ai muốn làm việc với một người làm công việc đó chỉ vì tiền. Tôi biết rằng tôi chỉ muốn làm việc với người chịu trách nhiệm về công việc của họ. Và bạn? Mặt khác, không cần thiết phải chịu trách nhiệm quá mức. Nếu tất cả những gì bạn thực sự lo lắng là cuộc tranh luận muôn thuở về các tab hoặc khoảng trống, bạn có thể cần phải dùng thuốc an thần.

Tại sao kiến ​​trúc REST API lại trở nên phổ biến?

Nguồn: DZone Giao tiếp tức thì là một điều tuyệt vời. Tất cả chúng ta đều quen với việc có thể liên lạc ngay lập tức với mọi nơi trên thế giới. Từ máy tính để bàn hoặc thiết bị di động, chúng ta có thể mua, đăng, đính kèm và chọn bất cứ thứ gì, ở bất cứ đâu. Chúng ta được kết nối với nhau và với thế giới hơn bao giờ hết. Nhưng làm thế nào điều này xảy ra? Làm thế nào để dữ liệu đến với chúng ta “từ đó”? Các thiết bị và ứng dụng giao tiếp với nhau bằng giao diện lập trình ứng dụng hoặc API. Đây chính xác là động cơ “dưới mui xe”. Nó luôn ở phía sau hậu trường và chúng ta có xu hướng nghĩ nó như một điều gì đó bình thường, nhưng chính API mới tạo ra tất cả khả năng tương tác mà chúng ta tin tưởng.

API là gì?

Nói một cách đơn giản, API là một trình nhắn tin chấp nhận các yêu cầu, cho hệ thống biết bạn muốn làm gì và sau đó trả lời phản hồi cho bạn. Để có ví dụ trực quan, hãy tưởng tượng API như một người phục vụ trong một nhà hàng. Hãy tưởng tượng rằng bạn đang ngồi vào bàn, cầm thực đơn trên tay và nhà bếp là một phần của hệ thống sẽ chuẩn bị món ăn cho bạn. API là liên kết sẽ truyền đơn đặt hàng của bạn đến nhà bếp và giao thức ăn đến bàn.

Hãy lấy một ví dụ thực tế:

Tất cả chúng ta đều quen thuộc với quá trình tìm kiếm chuyến bay trực tuyến và biết rằng để đặt chuyến bay, chúng ta sẽ phải tương tác với trang web của hãng hàng không. Bạn truy cập cơ sở dữ liệu của họ để xem liệu có chỗ trống vào một ngày cụ thể hay không và bạn có thể phải trả bao nhiêu chi phí dựa trên yêu cầu chuyến bay của mình. Nhưng nếu bạn không sử dụng trang web của hãng hàng không có quyền truy cập trực tiếp vào thông tin thì sao? Điều gì sẽ xảy ra nếu bạn sử dụng dịch vụ đặt vé trực tuyến thu thập thông tin từ các hãng hàng không khác nhau? Dịch vụ này tương tác với API của hãng hàng không, trong đó API là giao diện, giống như người phục vụ hữu ích của chúng tôi, yêu cầu thông tin từ dịch vụ trực tuyến về việc đặt chỗ và lựa chọn ưu tiên về bữa ăn hoặc hành lý của hành khách. API sau đó nhận phản hồi của hãng hàng không và gửi lại cho dịch vụ trực tuyến, nơi hiển thị thông tin cho hành khách. Quá trình tương tự cũng xảy ra giữa tất cả các ứng dụng, dữ liệu và thiết bị khác. Tất cả chúng đều có API cho phép máy tính điều khiển chúng và điều này cuối cùng tạo ra khả năng giao tiếp.

Có những loại API nào?

Kiến trúc API có thể được triển khai theo hai cách chính: một trong những cách triển khai truyền thông tin này là SOAP và cách chính còn lại là REST. Chúng tôi đã xác định rằng API cung cấp khả năng liên lạc giữa hai ứng dụng. Bây giờ chúng ta sẽ tìm hiểu chính xác SOAP và REST phù hợp với kiến ​​trúc truyền thông như thế nào.

API xà phòng

SOAP (Giao thức truy cập đối tượng đơn giản) là một dịch vụ web tuân theo các thông số kỹ thuật với các nguyên tắc giao tiếp nhất định được thiết lập giữa cơ quan trung tâm có tên là W3C và bộ thông số kỹ thuật cốt lõi. Bộ này bao gồm:

• XÀ BÔNG
• WSDL
• UDDI

SOAP là một giao thức xác định cách hai ứng dụng sẽ giao tiếp với nhau. Hai ứng dụng phải tuân theo một định dạng chung khi giao tiếp với nhau và định dạng chung này phải dựa trên ngôn ngữ XML. XML trong API SOAP phải tuân theo tiêu chuẩn Thông báo SOAP, bao gồm Phong bì, Tiêu đề và Nội dung.

API REST

Đây là một khái niệm rất quan trọng nhưng thường bị hiểu sai về dịch vụ web, vì vậy hãy cùng giải mã ý nghĩa của REST hoặc RESTful API. REST là một dịch vụ web khởi tạo giao tiếp giữa hai ứng dụng bằng các nguyên tắc kiến ​​trúc riêng của nó. Kiến trúc REST là kiểu kiến ​​trúc không tuân theo bất kỳ giao thức nào, không có thông số kỹ thuật nghiêm ngặt và không có cơ quan trung ương nào kiểm soát các thông số kỹ thuật. Điều này làm cho REST trở nên linh hoạt trong việc sử dụng hoặc tạo bất kỳ loại dịch vụ nào. Khi những nguyên tắc này được áp dụng khi tạo một dịch vụ web, chúng ta sẽ có được một dịch vụ web RESTful. Bây giờ chúng ta hãy đi sâu hơn một chút và tìm hiểu các nguyên tắc dựa trên kiến ​​trúc REST.

Giao diện hợp nhất

Trong kiến ​​trúc RESTful, mọi thứ đều có thể được coi là tài nguyên. Ví dụ: nếu bạn đang cố gắng tạo một ứng dụng cho hệ thống quản lý nhân viên. Ứng dụng này có thể được phát triển bằng bất kỳ ngôn ngữ nào, trên bất kỳ nền tảng nào và cho bất kỳ nền tảng nào. Tương tự như vậy, bất kỳ cơ sở dữ liệu nào cũng có thể được sử dụng để xử lý các dịch vụ nội bộ. Khái niệm tài nguyên trong REST API ngụ ý rằng người dùng có thể xác định bất kỳ thông tin hoặc bất kỳ mô-đun nào làm tài nguyên. Với hệ thống quản lý nhân viên, người tạo có thể xác định tài nguyên nhân viên, các phòng ban và bất kỳ mô-đun nào khác được sử dụng trong ứng dụng.

Không quốc tịch

Trong kiến ​​trúc RESTful, tất cả các phản hồi và yêu cầu cũng như mọi giao tiếp giữa các máy chủ đều không có trạng thái. Điều này có nghĩa là máy chủ không duy trì trạng thái hiện tại của hệ thống, máy khách có thể gửi yêu cầu tự hoàn thành. Và yêu cầu này không phụ thuộc vào bất kỳ yêu cầu nào trước đó. Ví dụ: nếu bạn đang mua sắm trực tuyến và thêm mặt hàng vào giỏ hàng, máy chủ sẽ không duy trì trạng thái giỏ hàng của bạn, vì vậy mỗi khi người dùng gửi yêu cầu đến máy chủ, nó sẽ chứa trạng thái của giỏ hàng tại thời điểm yêu cầu đã được thực hiện. Khi không có trạng thái, máy chủ sẽ không có chi phí để lưu trữ hoặc duy trì phiên, do đó nó sẽ cải thiện hiệu suất của dịch vụ web.

Khả năng lưu trữ

Trong giao thức trước, chúng tôi nhận thấy rằng trong kiến ​​trúc RESTful, máy chủ không lưu trạng thái phiên, tất cả quá trình lưu vào bộ đệm đều diễn ra ở phía máy khách. Bất cứ khi nào máy khách gửi yêu cầu đến máy chủ, máy chủ sẽ trả về phản hồi chứa dữ liệu thực tế cũng như siêu dữ liệu khác để cho máy khách biết liệu có nên lưu trữ phản hồi cục bộ hay không.

Hệ thống đa cấp

Nguyên tắc REST nêu rõ rằng bất cứ khi nào có giao tiếp giữa máy khách và máy chủ, có thể có nhiều lớp giữa chúng và các lớp này có thể được sử dụng để thực hiện nhiều mục đích như dịch tin nhắn, nâng cao hiệu suất, bộ nhớ đệm và nhiều thứ khác. Mỗi cấp độ giao tiếp có một nhiệm vụ cụ thể. Với nhiều lớp giao tiếp, hệ thống hoạt động hiệu quả, cải thiện tốc độ và độ bền.

Mã theo yêu cầu

Đây là một hạn chế tùy chọn của dịch vụ web RESTful hoạt động khi người dùng gửi yêu cầu để nhận phản hồi. Phản hồi có thể chạy mã phía máy khách. Nguyên tắc này mở rộng chức năng của giao tiếp.

Tại sao API REST ngày càng được sử dụng thường xuyên hơn?

REST phần lớn dễ sử dụng hơn, linh hoạt hơn và có một số lợi thế so với SOAP. Ví dụ: bạn không cần các công cụ đắt tiền để tương tác với bất kỳ dịch vụ web nào. Kiến trúc REST đơn giản hơn, có thể dễ dàng tùy chỉnh và không yêu cầu các kỹ năng đặc biệt khi tạo mô hình giao tiếp. Sử dụng nó hiệu quả vì nó có thể sử dụng phía máy khách của máy chủ để lưu trữ thông tin liên quan đến máy khách. REST sử dụng các định dạng tin nhắn nhỏ hơn và cung cấp khả năng tương tác nhanh hơn vì không yêu cầu xử lý tốn thời gian. REST cũng gần hơn với các công nghệ web khác khi nói đến triết lý thiết kế.

SOAP hay REST?

Đối với các yêu cầu của một ứng dụng web điển hình, SOAP thường là quá mức cần thiết. REST là một giải pháp đơn giản hơn có mọi thứ bạn cần khi ứng dụng web cần API. Tuy nhiên, đôi khi API cần phức tạp hơn một chút để hoàn thành nhiệm vụ. Ví dụ: nếu cần có API cho các yêu cầu tự động thì API SOAP sẽ là lựa chọn tốt hơn cho trường hợp đó. Nói một cách đơn giản, hãy chọn SOAP nếu vấn đề lớn và phức tạp và chọn REST nếu bạn cần một giải pháp đơn giản.