Đây có phải là một mô hình chống chế độ khác và tôi nên ngừng sử dụng nó hay đây là thiết kế thông minh?

Về cơ bản, tôi đã cố gắng thực hiện các thao tác sau khi tạo dịch vụ REST:

1. HTML được yêu cầu
2. dịch vụ trả về trang web mong muốn nhưng không có "tài nguyên" được yêu cầu, vd. dữ liệu
3. trang web chứa JavaScript phát hành yêu cầu AJAX cho cùng một dịch vụ (loại nội dung khác nhau)
4. dịch vụ sau đó trả về dữ liệu thực tế (JSON) và trang hiển thị nó

Một mặt có vẻ không hiệu quả (2 yêu cầu) nhưng sau đó tôi đã sử dụng điều này, "hiệu suất không có gì đáng lo ngại", có nghĩa là ứng dụng nội bộ có lưu lượng truy cập thấp và các trang web đơn giản và tải nhanh.

Lý do tôi kết thúc với điều này là vì trang web sau đó có thể gần như là Html + JavaScript thuần túy và hầu như không yêu cầu công cụ phía máy chủ, đặc biệt là không có vòng lặp, để tạo các bảng và nội dung như vậy (mà tôi nghĩ là rất xấu so với những thứ như slickgrid), ví dụ như tách dữ liệu và chế độ xem.

Bây giờ trước khi tôi bắt đầu sử dụng nó, đây có phải là một ý tưởng tốt hay tôi nên dừng việc đó lại?

Nếu bạn yêu cầu tài nguyên và nó không chứa dữ liệu, thì đó không phải là dịch vụ REST. Dịch vụ cung cấp dữ liệu thực tế trong json có thể, nhưng phần HTML thì không. Đối với một ứng dụng web, nó không thành vấn đề.

Kỹ thuật này hoạt động, nhưng bạn cần nhận thức được những hạn chế của nó:

1. Các công cụ tìm kiếm không giải thích JavaScript, vì vậy trang web được triển khai như thế sẽ không thể được Google và các lượt thích có thể lập chỉ mục. Đối với ứng dụng nội bộ, điều đó không thành vấn đề, đối với công chúng phải đối mặt với nó sẽ là vấn đề quan trọng.
2. Người dùng có nhu cầu đặc biệt (như những người sử dụng thiết bị đầu cuối chữ nổi) sử dụng các trình duyệt đặc biệt khá hạn chế và có thể không diễn giải đúng JavaScript.

Tôi cũng sẽ lưu ý rằng mã tạo HTML về cơ bản là giống nhau cho dù nó chạy phía máy chủ hay phía máy khách. Bạn có nhiều sự lựa chọn hơn về cả ngôn ngữ và khung công tác ở phía máy chủ và tôi chắc chắn cũng có một số tương đương của slickgrid.

Bạn có thể, và nên, vẫn duy trì việc tách dữ liệu và hiển thị ở phía máy chủ. Hệ thống mẫu có thể, và chỉ nên lấy dữ liệu làm cấu trúc dữ liệu hoặc thậm chí là json (đặc biệt nếu dịch vụ thực tế có ngôn ngữ khác với hệ thống mẫu) và chỉ cần mở rộng một mẫu với dữ liệu đó.

Và không, tôi không nghĩ về PHP; đó là hệ thống mẫu có khả năng thấp nhất ngoài kia (mặc dù có một số hệ thống tốt hơn được xây dựng trên nó). Tôi đang nghĩ Genshi hoặc XSLT hoặc một cái gì đó thậm chí còn tiên tiến hơn cung cấp các widget web.

Không có gì sai khi làm điều này, miễn là bạn chắc chắn cấu trúc mã của mình sạch sẽ. Bạn thậm chí có thể phục vụ nội dung tĩnh từ ví dụ như Apache chứ không phải dịch vụ web của bạn.

Đây là một thực hành tốt. Và nó đã được thực hiện mọi lúc, althogugh như @JanHudec chỉ ra, gọi đó là dịch vụ REST là sai. Nhưng nhiều trang web làm chính xác điều này vì lý do chính xác bạn chỉ ra.

Tôi sẽ không gọi nó là một mô hình chống, những gì bạn mô tả ít nhiều là một khách hàng béo , không hoàn toàn không giống như các dịch vụ như Trello. Trách nhiệm ban đầu của máy chủ là gửi DOM và bất kỳ tài nguyên nào là cần thiết để làm cho máy khách hoạt động. Tôi đã làm việc trên các dự án tương tự trong tự động hóa trung tâm dữ liệu và giám sát mạng.

Máy khách khởi động như một DOM thưa thớt, lấy một số dữ liệu qua XHR (đôi khi qua JSONP) và cuối cùng tự gắn vào máy chủ ổ cắm. Một ví dụ thậm chí cơ bản hơn sẽ là một ứng dụng trò chuyện.

Lý do duy nhất không để làm điều đó là nó có thể cực kỳ khó khăn để có được quyền. Nếu bạn cảm thấy thoải mái với lập trình chức năng không đồng bộ và tất cả các cuộc đua và các thách thức khác mà nó có thể đưa ra, thì bạn sẽ không gặp vấn đề gì trong việc duy trì nó. Quan trọng hơn, bạn sẽ không gặp vấn đề gì khi viết nó để người khác cuối cùng có thể duy trì nó.

Nếu ý nghĩ thêm nhiều tính năng bắt đầu làm bạn sợ hãi hoặc bạn bắt đầu thấy việc gỡ lỗi là một cơn ác mộng, thì bạn có thể muốn xem xét các phương pháp khác trong sản xuất trong khi bạn tiếp tục thử nghiệm và học hỏi.

Đây là một thiết kế hợp lệ miễn là bạn không tự đào một cái lỗ. Nếu bạn có gobs và gobs ngẫu nhiên ở mọi nơi thay vì giao diện sạch thì có lẽ bạn muốn tái tạo yếu tố hoặc đi về dự án theo cách khác. Hầu hết các chức năng của bạn được xác định để thực thi một khi tất cả tải tài nguyên phải ẩn danh và được nhập từ giao diện sạch. Nếu họ không, bạn có thể gặp rắc rối.

như @Jan Hudec đã nói, cách tiếp cận của bạn chắc chắn không thể được gọi là REST. Mặc dù phần mà khách hàng yêu cầu tài nguyên có thể. Sẽ tốt hơn nếu khách hàng xử lý phần trình bày, giống như backbone. Nó giao tiếp với máy chủ REST để lấy tài nguyên và hiển thị chúng bằng cách sử dụng views.

Nó có thể là một mô hình chống, nhưng tôi nghĩ đó cũng là tương lai của các ứng dụng web. Tuy nhiên, thay vì mucking về JavaScript, ít nhất bạn nên sử dụng một thư viện tạo khuôn mẫu. Một giải pháp tốt hơn là khung MVC phía máy khách như AngularJS (hiện tại tôi đang sử dụng).

Đối với một số tài liệu tham khảo khác, đây là một bài đăng blog phổ biến so sánh một số khung và đây là một trang web thực hiện cùng một chương trình bằng nhiều khung.

Ngoài ra: Nhận xét của Jan Hudec về tương tác công cụ tìm kiếm và trình đọc màn hình là hợp lệ. Nếu bạn đang làm việc trên một trang web thương mại điện tử (nơi có vấn đề về pagerank), thì có lẽ bạn không muốn sử dụng các khung công tác phía máy khách. Nhưng đối với các ứng dụng nội bộ, chúng thường không phải là mối quan tâm.

Những gì bạn làm âm thanh tốt! Tuy nhiên nếu phản hồi json của bạn có chứa bất kỳ HTML nào thì bạn sẽ lãng phí thời gian của mình.

Một điểm khác là khách hàng câm của bạn có thể sẽ nhận được dữ liệu json của nó từ một dự án khác. Bạn nên nhắm đến sự tách biệt thích hợp giữa máy khách và dịch vụ, sau đó bạn sẽ có một dịch vụ RESTful thích hợp