Dịch vụ API MVC và RESTful

MVC khá đơn giản. Có một Mô hình, Bộ điều khiển và Chế độ xem. Khi chúng tôi tạo một trang web, tất cả sẽ kết hợp với nhau khi ' client gửi yêu cầu từ khóa REST đến máy chủ -> máy chủ khớp URL được yêu cầu với hành động của bộ điều khiển -> sau đó gọi (các) mô hình để thu thập / xử lý dữ liệu, nhận được kết quả -> và trả lại kết quả cho khách hàng dưới dạng trang HTML (xem) '.

Điều gì xảy ra nếu chúng ta đang nói về một dịch vụ web RESTful API thuần túy? Sau đó, luồng có dạng như ' client gửi yêu cầu từ khóa REST đến máy chủ -> máy chủ khớp URL được yêu cầu với hành động của bộ điều khiển -> sau đó gọi (các) mô hình để thu thập / xử lý dữ liệu, nhận kết quả -> và trả về kết quả trở lại máy khách trong JSON '. Tương tự như trước đây, nhưng không có 'view' ... hay đúng hơn, JSON được tạo có thể được coi là 'view'. Theo một nghĩa nào đó, chúng tôi chỉ sử dụng phần MC của MVC. Có phải đó là cách nó nên được thực hiện? Hoặc có bất kỳ mẫu nào khác, phù hợp hơn cho dịch vụ chỉ API thay vì MVC không?

MVC là một mô hình từ thế giới Smalltalk liên quan đến cách các hệ thống hướng đối tượng có thể có UI.

Các khung web ban đầu đã lấy ý tưởng chung (tách logic kinh doanh, kiểm soát logic và xem logic) và áp dụng nguyên tắc này vào cách chúng cấu trúc ứng dụng web. Trước đó, không có gì lạ khi có sự hỗn loạn về mã thế hệ HTML bên trong các đối tượng miền hoặc logic nghiệp vụ trong các mẫu HTML (nghĩ rằng PHP rất sớm)

Vấn đề là MVC gốc từ thế giới Smalltalk không thực sự là MVC trong hầu hết các khung web. Một đầu ra HTML không thực sự là một "khung nhìn" theo nghĩa là Smalltalk hiểu màn hình UI.

Vì vậy, đó là lý do đầu tiên để không quá bận tâm về việc bạn có đang theo dõi MVC đúng cách hay không. Hầu như không có gì là. Hãy coi nó như một sự phân chia chặt chẽ và hơn nữa là một hướng dẫn của Hey sẽ không hay nếu các mẫu HTML của chúng tôi không đầy đủ logic kinh doanh.

Thứ hai MVC chỉ là một cách cấu trúc mã phía máy chủ. Nó thực sự không có gì để làm với REST / HTTP. REST quan tâm đến cách khách hàng và máy chủ giao tiếp. Sẽ không quan tâm nếu đại diện mà máy chủ gửi cho máy khách trong một mẫu HTML mất rất nhiều để xây dựng với một công cụ tạo khuôn mẫu hoặc một đối tượng JSON là một cuộc gọi trong bộ điều khiển.

Nếu bạn không nghĩ rằng máy chủ của bạn cần một lớp "xem" thì tốt. Bạn vẫn sẽ thu được lợi ích khi tách logic nghiệp vụ (ví dụ mô hình) khỏi các bộ điều khiển đang xử lý một yêu cầu HTTP cụ thể, ngay cả khi tất cả các bộ điều khiển thực hiện cuộc gọi phân tích cú pháp JSON trên một số đối tượng và trả về dữ liệu đó.

Chế độ xem là lớp chịu trách nhiệm hiển thị thông tin có thể được giải thích bởi người dùng / khách hàng của ứng dụng của bạn (không nói người dùng phải là người thực tế). JSON là định dạng hoàn toàn hợp lệ cho một lớp xem, máy tính hiểu điều đó.

Miễn là lớp khung nhìn xuất bản thông tin mà người dùng có thể sử dụng để ảnh hưởng đến các mô hình trong ứng dụng của bạn, không quan trọng là khung nhìn trông như thế nào, nó vẫn là một khung nhìn, một lớp đóng vai trò là phần mềm trung gian giữa người dùng và hệ thống .

MVC khá đơn giản.

Martin Fowler, có lẽ, không đồng ý với điều này :

Những người khác nhau đọc về MVC ở những nơi khác nhau sẽ lấy những ý tưởng khác nhau từ nó và mô tả những điều này là 'MVC'.

Tiếp tục ...

Khi chúng tôi tạo một trang web, tất cả sẽ kết hợp với nhau khi 'client gửi yêu cầu từ khóa REST đến máy chủ -> máy chủ khớp URL được yêu cầu với hành động của bộ điều khiển -> sau đó gọi (các) mô hình để thu thập / xử lý dữ liệu, nhận được kết quả -> và trả lại kết quả cho khách hàng dưới dạng trang HTML (xem) '.

OK, đây là một chút rối

MVC, dù nó là gì, là một tập hợp các ý tưởng để thực hiện giao diện người dùng.

REST là một tập hợp các ràng buộc kiến ​​trúc để xây dựng các ứng dụng quy mô lớn.

Web, đó là những gì bạn đang nói ở đây, là một ứng dụng quản lý tài liệu khổng lồ được xây dựng bằng hầu hết các ràng buộc tương tự.

Điểm tương đồng bạn đang thấy giữa hai người là (chọn lựa) không chính xác, hoặc hời hợt.

Các nhà hàng có hiểu biết chung về HATEOAS , "siêu văn bản là công cụ của trạng thái ứng dụng" và điều đó sẽ gửi các báo động vang lên trong đầu bạn - tại sao một chế độ xem lại là một công cụ trạng thái ? Nếu chúng ta đặt câu hỏi về tiền đề và tìm kiếm bằng chứng bổ sung, chúng ta cũng có thể nhận thấy hai điều kỳ lạ.

Đầu tiên, chúng ta có thể đưa máy chủ HTTP ra khỏi phương trình hoàn toàn bằng cách tải HTML từ đĩa. Trình duyệt hoàn toàn hài lòng với điều này, miễn cho một số biến thể nhỏ trong hành vi có thể phát sinh từ sự thay đổi trong url cơ sở. Các khung nhìn thường không tiếp tục hoạt động khi chúng bị ngắt hoàn toàn khỏi mô hình và bộ điều khiển như thế.

Thứ hai, nếu chúng ta quan sát một trình duyệt hiện đại một cách cẩn thận, chúng tôi sẽ nhận thấy rằng có nhiều chế độ xem HTML. Nhiều chế độ xem của một chế độ xem có vẻ như là một ý tưởng thực sự lạ, nhưng chắc chắn có phần trình bày chính, với một loạt các đánh dấu văn bản đáp ứng cử chỉ của người dùng, và sau đó có điều "Chế độ xem nguồn" hiển thị HTML thô và cũng phản hồi cử chỉ người dùng. Đó là tất cả các con rùa xuống!

Tất nhiên, câu trả lời cho câu đố là HTML không phải là chế độ xem. Bộ sưu tập các widget trong trình duyệt là chế độ xem và chúng đang liên lạc với Mô hình Đối tượng Tài liệu , được khởi tạo bằng cách đọc HTML.

Nói cách khác, HTML là một đại diện của nhà nước, giống như Roy T. Fielding đã hứa.

Điều gì xảy ra nếu chúng ta đang nói về một dịch vụ web RESTful API thuần túy ...? Tương tự như trước đây, nhưng không có 'lượt xem'

Chính xác hơn, giống như trước đây: không có chế độ xem. JSON, giống như HTML, là một đại diện của trạng thái, phù hợp để vượt qua các ranh giới quá trình.

Hãy suy nghĩ "DTO" hoặc "Tin nhắn" và suy luận của bạn sẽ ít có khả năng khiến bạn lạc lối.

Có phải đó là cách nó nên được thực hiện?

Truyền JSON làm dạng xem hoặc sử dụng nó làm mô hình khung nhìn để xây dựng khung nhìn không vi phạm mẫu.

Tôi đang sử dụng cùng một kiến ​​trúc trong ứng dụng hiện tại mà tôi đang làm việc và nó đang hoạt động rất tốt. Cùng với một số khung công tác JS đẹp, bạn có thể tạo ra một số thiết kế thực sự đáp ứng.

Hoặc có bất kỳ mẫu nào khác, phù hợp hơn cho dịch vụ chỉ API thay vì MVC không?

Thành thật mà nói, không có ý kiến. Nhưng tôi nghĩ rằng việc bạn có sử dụng MVC hay không trong API không quan trọng. Sử dụng bất cứ điều gì bạn thấy thuận tiện. Khi nói về các dịch vụ web, có rất nhiều khía cạnh quan trọng hơn để xem xét (không liên quan trực tiếp đến MVC), ví dụ: bảo mật, tính nhất quán, tính sẵn sàng, v.v.