Trong ngành , tích hợp đóng vai trò quan trọng trong thiết kế ứng dụng. Một trong những công nghệ chính cho việc này là . Kiến thức về REST API là một kỹ năng quan trọng đối với mọi chuyên gia công nghệ. Trong bài viết này, chúng tôi sẽ trình bày 25 câu hỏi API REST giúp bạn chuẩn bị cho cuộc phỏng vấn xin việc và cải thiện kỹ năng của mình. Thích đọc sách! phát triển phần mềm API REST Trước hết, người phỏng vấn thường chia các câu hỏi về REST API thành lý thuyết và thực tế. Đầu tiên, họ hỏi 2-3 câu hỏi lý thuyết về thuật ngữ và phương thức yêu cầu HTTP, sau đó bạn nhận được một nhiệm vụ thực tế là đưa ra một yêu cầu. Bài viết này chứa các câu hỏi lý thuyết thường gặp và tôi dự định xuất bản các ví dụ về các nhiệm vụ thực tế liên quan đến API REST trong bài viết tiếp theo. Chúng tôi không biết trước bạn sẽ nhận được những câu hỏi gì trong cuộc phỏng vấn, nhưng tôi chắc chắn rằng trong quá trình xem xét danh sách các câu hỏi điển hình của chúng tôi, bạn có thể sẽ tìm hiểu sâu hơn về chủ đề và nâng cao kiến thức của mình về API REST trong Mọi tình huống. Bây giờ, hãy đi từ đơn giản đến phức tạp, bắt đầu với thuật ngữ cơ bản và tiếp tục với phần có các câu hỏi phức tạp hơn. 1. REST là gì? Trả lời: Có ba thuật ngữ được sử dụng khi đề cập đến REST thường được coi là giống nhau, nhưng điều này không hoàn toàn đúng. Các thuật ngữ này là REST, REST API và RESTful API. Bây giờ sẽ có câu trả lời về REST, thuật ngữ này là viết tắt của Chuyển giao trạng thái đại diện và là một kiểu kiến trúc dựa trên giao thức HTTP (Giao thức truyền siêu văn bản) để phát triển các ứng dụng có giao diện người dùng và/hoặc tích hợp với các hệ thống bên ngoài. REST mô tả các nguyên tắc mà các dịch vụ API được thiết kế phải tuân theo. Những nguyên tắc này đảm bảo rằng các yêu cầu được chuyển giữa máy khách và máy chủ bằng HTTP. 2. API REST là gì? Trả lời: API là giao diện lập trình cho phép các ứng dụng riêng lẻ giao tiếp và trao đổi dữ liệu. Ví dụ: ứng dụng giao đồ ăn có thể sử dụng API Google Maps để theo dõi vị trí của người chuyển phát nhanh và hiển thị vị trí đó trên bản đồ. API REST là API tuân theo các nguyên tắc của REST, xử lý tất cả dữ liệu dưới dạng tài nguyên, mỗi dữ liệu được biểu thị bằng một Mã định danh tài nguyên thống nhất (URI) duy nhất. 3. API RESTful là gì? Trả lời: RESTful API là API được thiết kế theo các quy tắc (hoặc bạn cũng có thể nói là “nguyên tắc”) của REST. Nói cách khác, sự khác biệt giữa REST API và RESTful API là về mặt thuật ngữ. Trường hợp đầu tiên đề cập đến một bộ quy tắc REST và trường hợp thứ hai đề cập đến việc triển khai một API cụ thể theo các quy tắc REST. Thuật ngữ RESTful API thường được thay thế bằng REST API hoặc thậm chí REST hoàn toàn vì mục đích ngắn gọn. Khi các nhà phân tích hệ thống vẽ các mũi tên có nhãn REST trên sơ đồ ứng dụng, chúng có nghĩa là API RESTful. 4. Hai nguyên tắc chính của REST là gì? Trả lời: Các yêu cầu REST API phải tuân theo hai nguyên tắc cơ bản: Tách thành client và server: Sự tương tác giữa client và server được thực hiện dưới dạng yêu cầu và phản hồi. Chỉ khách hàng mới có thể đưa ra yêu cầu và chỉ máy chủ mới có thể gửi phản hồi để hoạt động độc lập với nhau. Giao thức đơn: Tương tác giữa máy khách và máy chủ phải được thực hiện bằng một giao thức duy nhất. Đối với REST, giao thức này là HTTP. 5. Bạn biết những nguyên tắc nào khác của REST? Trả lời: Bạn có thể kể tên ít nhất 4 nguyên tắc nữa. Các yêu cầu API REST không lưu trữ trạng thái trên máy chủ và có thể đi qua các lớp máy chủ và được lưu vào bộ đệm. Bạn cũng có thể gửi mã thực thi cho máy khách trong phản hồi của máy chủ. Máy chủ không trạng thái: Máy chủ không lưu trữ bất kỳ thông tin nào về các yêu cầu/phản hồi trong quá khứ. Mỗi yêu cầu và phản hồi chứa tất cả thông tin cần thiết để hoàn thành tương tác. Giao tiếp không trạng thái giúp giảm tải máy chủ, tiết kiệm bộ nhớ và cải thiện hiệu suất. Hệ thống phân lớp: Có thể có các máy chủ bổ sung giữa máy khách và máy chủ API dưới dạng các lớp để thực hiện các chức năng khác nhau. Trong hệ thống được xây dựng trên nguyên tắc REST, các lớp có tính mô-đun và có thể được thêm vào và xóa mà không ảnh hưởng đến giao tiếp giữa máy khách và máy chủ. Khả năng lưu vào bộ đệm: Phản hồi của máy chủ cho biết liệu tài nguyên của nó có được lưu vào bộ đệm hay không để khách hàng có thể lưu vào bộ đệm bất kỳ tài nguyên nào nhằm cải thiện hiệu suất. Mã theo yêu cầu: Máy chủ có thể gửi mã thực thi cho khách hàng để phản hồi việc thực thi trong ứng dụng khách. 6. Tài nguyên là gì? Trả lời: Trong REST, mọi đối tượng có thể truy cập ở phía máy chủ đều được chỉ định là tài nguyên. Tài nguyên là một đối tượng có loại, dữ liệu được liên kết với nó, mối quan hệ với các tài nguyên khác trên máy chủ và danh sách các phương thức có thể được sử dụng để làm việc với nó. Ví dụ: tài nguyên có thể là tệp HTML hoặc văn bản, tệp dữ liệu, hình ảnh hoặc video hoặc tệp mã thực thi. Một tài nguyên được xác định bởi Mã định danh tài nguyên thống nhất hoặc URI. Khách hàng truy cập tài nguyên bằng cách sử dụng URI của họ trong các yêu cầu HTTP. 7. URL là gì? Trả lời: URI là viết tắt của Mã định danh tài nguyên thống nhất. Đây là một chuỗi xác định tài nguyên trên máy chủ. Mỗi tài nguyên có URI riêng, khi được đưa vào yêu cầu HTTP, sẽ cho phép khách hàng truy cập và thực hiện các hành động trên tài nguyên đó. Quá trình tham chiếu đến một tài nguyên bằng URI của nó được gọi là "địa chỉ". 8. CRUD là gì? Trả lời: CRUD là viết tắt của "Tạo, Đọc, Cập nhật, Xóa". Đây là bốn hành động chính có thể được thực hiện trên cơ sở dữ liệu thông qua API REST. Mỗi hành động có phương thức yêu cầu HTTP riêng: Tạo = ĐĂNG Đọc = NHẬN Cập nhật = PUT Xóa = XÓA 9. Tải trọng trong phản hồi của máy chủ có ý nghĩa gì? Trả lời: Tải trọng phản hồi HTTP đề cập đến dữ liệu tài nguyên được khách hàng yêu cầu. Đây còn được gọi ngắn gọn là "tải trọng phản hồi HTTP". Dữ liệu này có thể ở dạng JSON, XML, HTML, hình ảnh, tệp, v.v., tùy thuộc vào chính xác những gì máy chủ cung cấp. 10. Tin nhắn REST là gì? Trả lời: Nhắn tin trong REST đề cập đến việc trao đổi tin nhắn giữa máy khách và máy chủ. Giao tiếp luôn bắt đầu bằng việc máy khách thực hiện yêu cầu HTTP tới máy chủ. Máy chủ xử lý yêu cầu này và sau đó gửi lại phản hồi HTTP cho biết trạng thái của yêu cầu và mọi tài nguyên mà khách hàng yêu cầu. 11. Trình môi giới tin nhắn trong REST là gì? Trả lời: Trong ngữ cảnh của REST, thuật ngữ "trung gian thông báo" là một phần mềm trung gian dùng để truyền thông điệp giữa các thành phần hoặc hệ thống khác nhau trong một ứng dụng phân tán. Nhà môi giới có thể cung cấp trao đổi dữ liệu không đồng bộ, xếp hàng tin nhắn và xử lý tin nhắn giữa các mô-đun hệ thống khác nhau. Môi giới tin nhắn có thể được sử dụng để quản lý các hoạt động không đồng bộ hoặc gửi thông báo. Trình môi giới tin nhắn không phải là phần tử REST gốc vì... REST tập trung vào giao tiếp đồng bộ giữa máy khách và máy chủ bằng cách sử dụng các yêu cầu HTTP. 12. REST hỗ trợ những phương thức yêu cầu HTTP nào? Trả lời: Phương thức yêu cầu HTTP chỉ định hành động mong muốn mà máy chủ sẽ thực hiện trên tài nguyên. Trong REST, có bốn phương thức chính để thực hiện các yêu cầu HTTP từ máy khách đến máy chủ: NHẬN: Yêu cầu tài nguyên từ máy chủ, phương thức này ở chế độ chỉ đọc. POST: Tạo tài nguyên mới trên máy chủ. PUT: Cập nhật tài nguyên hiện có trên máy chủ. DELETE: Xóa tài nguyên khỏi máy chủ. 13. Sự khác biệt giữa phương thức POST và PUT là gì? Trả lời: POST dùng để tạo tài nguyên trên máy chủ trong khi PUT dùng để thay thế tài nguyên tại một URI cụ thể bằng tài nguyên khác. Nếu bạn sử dụng PUT trên URI đã có tài nguyên được liên kết với nó, PUT sẽ thay thế nó. Nếu không có tài nguyên tại URI được chỉ định, PUT sẽ tạo một tài nguyên. PUT là idempotent, nghĩa là gọi nó nhiều lần sẽ chỉ tạo ra một tài nguyên. Điều này xảy ra vì mỗi lệnh gọi sẽ thay thế tài nguyên hiện có (hoặc tạo một tài nguyên mới nếu không có gì để thay thế). POST không bình thường. Ví dụ: nếu bạn gọi POST 10 lần thì 10 tài nguyên khác nhau sẽ được tạo trên máy chủ, mỗi tài nguyên có URI riêng. Mặc dù hiếm khi được sử dụng nhưng phản hồi POST có thể được lưu vào bộ đệm nhưng phản hồi PUT thì không. Các yêu cầu POST thường được coi là không thể lưu vào bộ nhớ đệm nhưng chúng có thể được lưu vào bộ nhớ đệm khi chứa thông tin rõ ràng về “độ mới” của dữ liệu. Câu trả lời chi tiết hơn là phản hồi cho yêu cầu POST (hoặc PATCH) có thể được lưu vào bộ đệm nếu dữ liệu "mới" và tiêu đề Vị trí nội dung (en-US) được đặt, nhưng điều này hiếm khi được triển khai. Do đó, nên tránh bộ nhớ đệm POST nếu có thể. 14. Các phần chính của yêu cầu HTTP là gì? Trả lời: Trong REST, có các thành phần cơ bản sau của một yêu cầu HTTP: Phương thức yêu cầu sẽ được thực hiện đối với tài nguyên (tức là GET, POST, PUT, DELETE). URI xác định tài nguyên được yêu cầu trên máy chủ. Phiên bản HTTP - tức là phiên bản nào sẽ có trong phản hồi của máy chủ. Tiêu đề yêu cầu HTTP chứa siêu dữ liệu về yêu cầu, chẳng hạn như tác nhân người dùng, định dạng tệp được khách hàng chấp nhận, định dạng nội dung yêu cầu, ngôn ngữ, tùy chọn bộ đệm, v.v. Nội dung của yêu cầu HTTP, nó chứa tất cả dữ liệu được liên kết với yêu cầu . Điều này chỉ cần thiết nếu yêu cầu thay đổi dữ liệu trên máy chủ bằng phương thức POST hoặc PUT. 15. Các phần chính của phản hồi HTTP là gì? Trả lời: Phản hồi HTTP được gửi từ máy chủ đến máy khách. Họ thông báo cho khách hàng rằng hành động được yêu cầu đã (hoặc chưa) được hoàn thành và việc cung cấp mọi tài nguyên được yêu cầu. Có bốn thành phần chính của phản hồi HTTP: Phiên bản HTTP được sử dụng. Thanh trạng thái có trạng thái yêu cầu và mã trạng thái phản hồi HTTP. Tiêu đề phản hồi HTTP với siêu dữ liệu về phản hồi, bao gồm thời gian, tên máy chủ, tác nhân người dùng, định dạng tệp tài nguyên được trả về, thông tin bộ nhớ đệm. Nội dung phản hồi HTTP chứa dữ liệu về tài nguyên được khách hàng yêu cầu 16. Đặt tên ít nhất 3 mã để phản hồi máy chủ HTTP thành công Trả lời: Máy chủ trả về các mã trạng thái hoạt động sau khi yêu cầu được xử lý thành công: 200 OK: Yêu cầu đã được hoàn thành thành công. 201 Created: Yêu cầu thành công và tài nguyên đã được tạo. 202 Accepted: Trạng thái này có nghĩa là máy chủ đã chấp nhận yêu cầu của khách hàng nhưng chưa hoàn tất việc xử lý yêu cầu đó. Quá trình xử lý có thể không đồng bộ. 17. Đặt tên ít nhất 4 mã phản hồi HTTP của máy chủ khi chuyển hướng yêu cầu Trả lời: Máy chủ trả về các mã trạng thái sau khi chuyển hướng yêu cầu: 301 Đã di chuyển vĩnh viễn: Trạng thái này cho khách hàng biết rằng tài nguyên được yêu cầu đã được chuyển vĩnh viễn sang một URL khác và khách hàng phải truy cập URL mới để truy cập tài nguyên. 302 Found: Trạng thái này cho biết tài nguyên đã được tạm thời chuyển sang một URL khác và khách hàng nên tạm thời sử dụng URL mới. Chuyển hướng tạm thời 307: Tương tự như 302, nhưng khách hàng phải sử dụng cùng một phương thức yêu cầu khi truy cập URL mới. Chuyển hướng vĩnh viễn 308: Tương tự như 301, nhưng khách hàng phải sử dụng cùng một phương thức yêu cầu khi truy cập URL mới 18. Kể tên ít nhất 4 mã cho phản hồi của máy chủ HTTP không thành công. Trả lời: Máy chủ trả về các mã sau khi yêu cầu không thành công: 400 Yêu cầu không hợp lệ: Yêu cầu không được hoàn thành do có lỗi trong yêu cầu, chẳng hạn như lỗi đánh máy hoặc thiếu dữ liệu. 401 trái phép: Yêu cầu không được hoàn thành do máy khách không được xác thực hoặc không có quyền truy cập vào tài nguyên được yêu cầu. 403 Bị cấm: Yêu cầu không được hoàn thành vì máy khách đã được xác thực nhưng không được phép truy cập tài nguyên được yêu cầu. 404 Not Found: Yêu cầu không được hoàn thành do máy chủ không thể tìm thấy tài nguyên được yêu cầu. 19. Kể tên ít nhất 3 mã lỗi máy chủ. Trả lời: Máy chủ trả về các mã sau khi có lỗi trên máy chủ: Lỗi máy chủ nội bộ 500: Yêu cầu không được hoàn thành do sự cố không mong muốn với máy chủ. 502 Bad Gateway: Yêu cầu không được hoàn thành do phản hồi không chính xác từ máy chủ ngược tuyến. 503 Dịch vụ không khả dụng: Máy chủ không thể xử lý yêu cầu do bảo trì, quá tải hoặc các xáo trộn tạm thời khác. Bạn có thể tìm thấy danh sách các mã HTTP phổ biến nhất tại đây 20. Sự khác biệt giữa REST và GraphQL là gì Trả lời: GraphQL là ngôn ngữ truy vấn cho phép khách hàng chỉ truy vấn dữ liệu họ cần. Trong GraphQL, máy khách xác định cấu trúc và định dạng của dữ liệu mà nó muốn nhận và máy chủ trả về dữ liệu đó theo yêu cầu đó. Điểm khác biệt chính là REST có định dạng yêu cầu và phản hồi cố định cho từng tài nguyên, trong khi GraphQL cho phép khách hàng xác định yêu cầu của họ và chỉ nhận thông tin họ cần, giúp sử dụng hiệu quả và linh hoạt hơn. 21. Sự khác biệt giữa REST và SOAP là gì? Trả lời: REST và SOAP (Giao thức truy cập đối tượng đơn giản) là hai cách tiếp cận để xây dựng API. Có 3 điểm khác biệt chính giữa chúng: SOAP là một giao thức nghiêm ngặt để xây dựng các API an toàn. REST không phải là một giao thức mà là một kiểu kiến trúc được quy định bởi một bộ nguyên tắc gọi là nguyên tắc REST. - API REST xây dựng đơn giản hơn, nhẹ hơn và thường nhanh hơn API SOAP. API SOAP được coi là an toàn hơn API REST, mặc dù API REST vẫn có thể triển khai các tính năng bảo mật để đảm bảo chúng khá an toàn. - REST cho phép lưu các phản hồi vào bộ đệm, còn SOAP thì không. SOAP mã hóa dữ liệu ở định dạng XML. - REST cho phép bạn mã hóa dữ liệu ở bất kỳ định dạng nào, mặc dù XML và JSON là phổ biến nhất. 22. Sự khác biệt giữa REST và AJAX là gì? Trả lời: JavaScript không đồng bộ hoặc AJAX là một tập hợp các công nghệ phát triển web được sử dụng trong các ứng dụng web. Về cốt lõi, AJAX cho phép một trang web gửi yêu cầu đến máy chủ và cập nhật giao diện của trang mà không cần phải cập nhật toàn bộ trang. Máy khách AJAX có thể sử dụng API REST trong các yêu cầu của nó, nhưng AJAX không nhất thiết phải hoạt động chỉ với API REST. API REST có thể giao tiếp với bất kỳ ứng dụng khách nào, cho dù ứng dụng đó có sử dụng AJAX hay không. Không giống như REST sử dụng các yêu cầu và phản hồi HTTP để trao đổi tin nhắn, AJAX gửi các yêu cầu của nó đến máy chủ bằng cách sử dụng đối tượng XMLHttpRequest được tích hợp trong JavaScript. Phản hồi của máy chủ được thực thi bằng mã JavaScript của trang để thay đổi nội dung của trang. 23. Cách tiếp cận "Hợp đồng đầu tiên" để phát triển API REST là gì? Trả lời: Cách tiếp cận Hợp đồng đầu tiên để phát triển API REST là một phương pháp trong đó đặc tả và hợp đồng API được tạo và xác định trước khi quá trình phát triển thực tế bắt đầu. Hợp đồng này đóng vai trò như một tài liệu quan trọng xác định cách khách hàng có thể tương tác với API và kết quả mong đợi sẽ thu được từ các yêu cầu khác nhau. 24. Hợp đồng đầu tiên mang lại lợi ích gì? Trả lời: Có thể kể đến những ưu điểm sau của phương pháp Contract First: Định nghĩa API rõ ràng: Đặc tả và hợp đồng API xác định cách API tương tác với khách hàng. Giảm rủi ro: Phê duyệt hợp đồng sơ bộ với khách hàng giúp giảm nguy cơ hiểu lầm và không đáp ứng được kỳ vọng phát triển API. Tài liệu được cải tiến: Văn bản hợp đồng thường đóng vai trò là tài liệu cho API, giúp sử dụng và tích hợp dễ dàng hơn. 25. Cách tiếp cận Code First để phát triển REST API là gì? Trả lời: Cách tiếp cận Code First để phát triển API REST là một phương pháp trong đó chức năng API được phát triển đầu tiên và sau đó đặc tả API được tạo tự động dựa trên chức năng đó. Điểm nổi bật của phương pháp Code First là các nhà phát triển tập trung vào việc viết logic API và sử dụng các công cụ cho phép họ tự động tạo tài liệu và thông số kỹ thuật dựa trên logic đó. Nhìn chung, cả hai phương pháp tiếp cận Code First và Contract First đều có thể được kết hợp trong cùng một dự án phát triển API. Trong trường hợp này, Code First được sử dụng để tạo mẫu nhanh, tiếp theo là Contract First để chính thức hóa hợp đồng. Tôi hy vọng bài viết này hữu ích cho bạn trong việc chuẩn bị cho một cuộc phỏng vấn xin việc hoặc làm mới kiến thức của bạn về REST API.
