Điều gì thực sự sai với điểm cuối trả về HTML thay vì dữ liệu JSON?

Khi tôi mới bắt đầu học PHP (khoảng 5 hoặc 6 năm trước) tôi đã học về Ajax và tôi đã trải qua "các giai đoạn":

1. Máy chủ của bạn trả về dữ liệu HTML và bạn đặt nó bên trong một của DOM innerHTML
2. Bạn tìm hiểu về các định dạng truyền dữ liệu, chẳng hạn như XML (và nói "oooh vậy đó là những gì nó được sử dụng cho) và sau đó là JSON.
3. Bạn trả về JSON và xây dựng giao diện người dùng của mình bằng mã JavaScript vanilla
4. Bạn chuyển sang jQuery
5. Bạn tìm hiểu về API, tiêu đề, mã trạng thái HTTP, REST , CORS và Bootstrap
6. Bạn tìm hiểu SPA và các khung công tác frontend ( React , Vue.js và AngularJS ) và tiêu chuẩn API JSON.
7. Bạn nhận được một số mã kế thừa doanh nghiệp và khi kiểm tra nó, thấy rằng họ thực hiện những gì được mô tả trong bước 1.

Khi tôi làm việc với cơ sở mã di sản này, tôi thậm chí không nghĩ rằng nó có thể trả về HTML (ý tôi là, bây giờ chúng tôi là chuyên gia phải không?), Vì vậy tôi đã gặp khó khăn khi tìm kiếm điểm cuối JSON trả về dữ liệu các cuộc gọi Ajax được đưa ra. Mãi đến khi tôi hỏi "lập trình viên" thì anh ta mới nói với tôi rằng nó đang trả lại HTML và được thêm trực tiếp vào DOM bằng InternalHTML.

Tất nhiên, điều này thật khó chấp nhận. Tôi bắt đầu nghĩ cách để cấu trúc lại điểm này thành các điểm cuối JSON, nghĩ về việc đơn vị kiểm tra các điểm cuối, v.v. Tuy nhiên, codebase này không có xét nghiệm. Không một ai. Và đó là hơn 200 nghìn dòng. Tất nhiên một trong những nhiệm vụ của tôi bao gồm đề xuất các phương pháp tiếp cận để kiểm tra toàn bộ, nhưng hiện tại chúng tôi vẫn chưa giải quyết được điều đó.

Vì vậy, tôi không ở đâu, trong một góc, tự hỏi: nếu chúng tôi không có bài kiểm tra nào, vì vậy chúng tôi không có lý do cụ thể nào để tạo điểm cuối JSON này (vì nó không "tái sử dụng": nó trả về dữ liệu chỉ phù hợp với phần đó của ứng dụng, nhưng tôi nghĩ rằng điều này đã được ngụ ý vì nó ... trả về dữ liệu HTML).

Chính xác thì điều gì là sai khi làm điều này?

Điều gì thực sự sai với điểm cuối trả về HTML thay vì dữ liệu JSON?

Không có gì thực sự. Mỗi ứng dụng có các yêu cầu khác nhau và có thể ứng dụng của bạn không được thiết kế để trở thành một SPA.

Có thể các khung công tác đẹp mà bạn đã trích dẫn (Angular, Vue, React, v.v.) không có sẵn tại thời điểm phát triển hoặc không được sử dụng trong các tổ chức enterprisey được sử dụng trong tổ chức của bạn.

Tôi sẽ nói với bạn điều này: một điểm cuối trả về HTML làm giảm sự phụ thuộc của bạn vào các thư viện JavaScript và giảm tải cho trình duyệt của người dùng vì không cần phải diễn giải / thực thi mã JS để tạo các đối tượng DOM - HTML đã có sẵn, đó chỉ là vấn đề phân tích các yếu tố và kết xuất chúng. Tất nhiên, điều này có nghĩa là chúng ta đang nói về một lượng dữ liệu hợp lý. 10 megabyte dữ liệu HTML không hợp lý.

Nhưng vì không có gì sai khi trả về HTML, nên những gì bạn đang mất khi không sử dụng JSON / XML về cơ bản là khả năng sử dụng điểm cuối của bạn làm API. Và đây là câu hỏi lớn nhất: nó có thực sự cần phải là một API không?

Liên quan: Có thể trả lại HTML từ API JSON không?

JSON và HTML thực hiện hai mục đích ngữ nghĩa khác nhau.

Nếu bạn đang điền một trang web có dữ liệu, hãy sử dụng JSON. Nếu bạn đang xây dựng một trang web từ các phần của trang web, hãy sử dụng HTML.

Chúng có thể giống như chúng giống nhau, nhưng chúng hoàn toàn không. Đối với một điều, khi bạn đang xây dựng một phần của trang web bằng HTML được máy chủ trả về, bạn đang làm việc phía máy chủ. Khi bạn liên kết dữ liệu với một trang web, bạn đang làm việc phía máy khách.

Ngoài ra, bạn phải cẩn thận với HTML để không liên kết chặt chẽ với một trang cụ thể. Toàn bộ quan điểm hiển thị một phần trang theo cách này là để các phần có thể được sử dụng lại và nếu bạn tạo một phần quá cụ thể, nó sẽ không được soạn thảo cho các trang khác. JSON không có vấn đề này, vì nó chỉ là dữ liệu, không phải cấu trúc trang web.

Vấn đề chính là nó kết hợp chặt chẽ máy chủ với máy khách, người phải biết cấu trúc HTML. Nó cũng làm cho các điểm cuối khó sử dụng hơn theo cách mới hoặc ứng dụng mới.

Trả lại dữ liệu đơn giản và để máy khách hiển thị nó giảm khớp nối và tăng tính linh hoạt và khả năng kiểm tra - bạn có thể chạy thử nghiệm đơn vị trên máy khách để lấy dữ liệu giả và chạy thử nghiệm đơn vị trên máy chủ để kiểm tra dữ liệu mong muốn.

Tôi nghĩ rằng bạn có một chút ngược. Bạn nói:

chúng tôi không có thử nghiệm nào, vì vậy chúng tôi không có lý do cụ thể để tạo điểm cuối JSON này

Một lý do để sử dụng một điểm cuối thích hợp sẽ là để bạn có thể kiểm tra nó. Tôi muốn nói rằng không có bài kiểm tra là một lý do rất tốt để bắt đầu viết một số. Đó là, nếu có bất kỳ logic nào sẽ phù hợp để kiểm tra.

200k dòng mã là rất nhiều để cấu trúc lại và có lẽ khó bảo trì. Phá vỡ một số điểm cuối và kiểm tra chúng có thể là một nơi tốt để bắt đầu.

Một lý do khác có thể là để tách máy chủ khỏi máy khách. Nếu trong tương lai xa, thiết kế ứng dụng hoặc bố cục thay đổi, sẽ dễ dàng làm việc với định dạng dữ liệu phù hợp hơn so với đầu ra HTML. Trong một thế giới lý tưởng, bạn sẽ chỉ phải thay đổi máy khách và không chạm vào máy chủ.

Có 3 cách (ít nhất là?) Để xây dựng một trang web:

• Tạo toàn bộ phía máy chủ trang.
• Trả về một trang cốt lõi từ máy chủ cộng với mã (JavaScript) và để trang lấy dữ liệu của nó và kết xuất vào phía máy khách HTML.
• Trả lại một phần trang cộng với mã và có mã tìm nạp các khối HTML được kết xuất sẵn mà nó có thể thả vào trang.

Người đầu tiên là tốt. Cái thứ hai cũng ổn. Đó là vấn đề cuối cùng.

Lý do rất đơn giản: bây giờ bạn đã chia việc xây dựng trang HTML thành các phần hoàn toàn bị ngắt kết nối. Vấn đề là một trong những bảo trì. Bây giờ bạn có hai thực thể riêng biệt chịu trách nhiệm quản lý các chi tiết của giao diện người dùng. Vì vậy, bạn phải giữ CSS và các chi tiết tương tự khác đồng bộ giữa hai phần riêng biệt. Bạn đã thay đổi chiều rộng của thanh bên? Tuyệt quá. Bây giờ đoạn HTML quay lại gây ra cuộn ngang vì các giả định của nó về chiều rộng của thanh bên không còn giữ được nữa. Bạn đã thay đổi màu nền cho khối đó? Tuyệt vời, bây giờ màu phông chữ của đoạn HTML của bạn bị xung đột vì nó giả sử màu nền khác và ai đó đã quên kiểm tra điểm cuối đó.

Vấn đề là bây giờ bạn đã phân tách kiến ​​thức nên tập trung ở một nơi duy nhất (cụ thể là logic trình bày) và điều này khiến cho việc đảm bảo tất cả các phần khớp với nhau một cách chính xác sẽ khó khăn hơn. Bằng cách sử dụng API JSON, thay vào đó, bạn có thể giữ tất cả logic đó ở mặt trước hoặc bạn có thể giữ tất cả trong các mẫu phía máy chủ nếu bạn kết xuất dữ liệu của mình thành HTML. Đó là về việc giữ kiến ​​thức / logic trình bày ở một nơi duy nhất, vì vậy nó có thể được quản lý một cách nhất quán và là một phần của một quy trình. HTML / CSS / JS đủ khó để giữ thẳng mà không phá vỡ nó thành nhiều mảnh nhỏ.

API JSON cũng có lợi ích bổ sung là làm cho dữ liệu có sẵn hoàn toàn độc lập với logic trình bày. Điều này cho phép nhiều người thuyết trình khác nhau , chẳng hạn như cả ứng dụng di động và trang web, tiêu thụ cùng một dữ liệu. Cụ thể, nó cho phép tiêu thụ dữ liệu mà không cần trình duyệt (như ứng dụng di động hoặc công việc định kỳ hàng đêm); những người tiêu dùng này thậm chí có thể không phân tích được HTML. (Tất nhiên điều này nhất thiết phải dựa vào tình huống dữ liệu giống nhau giữa những người tiêu dùng khác nhau hoặc người ta có thể sử dụng tập hợp con của người khác.) Dù bạn có cần khả năng này hay không tùy thuộc vào yêu cầu của ứng dụng cụ thể của bạn logic là cần thiết bất kể. Tuy nhiên, tôi sẽ nói rằng nếu bạn triển khai nó trước, bạn sẽ chuẩn bị tốt hơn cho sự phát triển trong tương lai.

Tôi sẽ nói rằng không có gì sai khi máy chủ trả về một đoạn HTML và giao diện người dùng gán nó cho .innerHTML của một số phần tử. Theo tôi, đây là cách dễ nhất để phát triển mã JavaScript không đồng bộ. Lợi ích là càng ít càng tốt được thực hiện bằng cách sử dụng JavaScript và càng nhiều càng tốt được thực hiện trong môi trường back-end được kiểm soát. Hãy nhớ rằng hỗ trợ JavaScript trong các trình duyệt khác nhau, nhưng back-end của bạn luôn có cùng phiên bản của các thành phần back-end, nghĩa là làm càng nhiều càng tốt trong back-end sẽ có nghĩa là càng ít tương thích phiên bản càng tốt.

Bây giờ, đôi khi bạn muốn nhiều hơn là một đoạn HTML. Ví dụ: mã trạng thái và đoạn HTML. Sau đó, bạn có thể sử dụng một đối tượng JSON có hai thành viên, statusCode và HTML, trong đó thứ hai có thể được gán cho .innerHTML của một số phần tử sau khi kiểm tra statusCode. Vì vậy, sử dụng JSON và sử dụng InternalHTML không có nghĩa là các cách tiếp cận độc quyền thay thế; chúng có thể được sử dụng cùng nhau.

Bằng cách sử dụng JSON, bạn thậm chí có thể có nhiều đoạn HTML trong cùng một phản hồi được gán cho .innerHTML của nhiều phần tử.

Tóm lại: hãy sử dụng .innerHTML. Nó làm cho mã của bạn tương thích với càng nhiều phiên bản trình duyệt càng tốt. Nếu cần thêm, hãy sử dụng JSON và .innerHTML cùng nhau. Tránh XML.

Không có gì sai về nguyên tắc . Câu hỏi là: Bạn muốn đạt được điều gì?

JSON là hoàn hảo để truyền dữ liệu. Nếu bạn gửi HTML thay vào đó và mong khách hàng trích xuất dữ liệu từ HTML, đó là thứ rác rưởi.

Mặt khác, nếu bạn muốn truyền HMTL sẽ được hiển thị dưới dạng HTML, thì hãy gửi nó dưới dạng HTML - thay vì đóng gói HTML thành một chuỗi, biến chuỗi thành JSON, truyền JSON, giải mã nó ở phía bên kia , nhận một chuỗi và trích xuất HTML từ chuỗi.

Và mới hôm qua tôi đã chạy vào mã đặt hai mục thành một mảng, biến mảng thành JSON, đặt JSON thành một chuỗi, đặt chuỗi bên trong một mảng, biến toàn bộ mảng thành JSON, gửi nó đến máy khách, được giải mã JSON, có một mảng chứa một chuỗi, lấy chuỗi, trích xuất JSON từ chuỗi, giải mã JSON và có một mảng có hai mục. Đừng làm vậy.

Tất cả điều này phụ thuộc vào mục đích của API, nhưng nhìn chung những gì bạn mô tả là một sự vi phạm khá mạnh mẽ trong việc phân tách các mối quan tâm :

Trong một ứng dụng hiện đại, mã API phải chịu trách nhiệm về dữ liệu và mã máy khách phải chịu trách nhiệm trình bày.

Khi API của bạn trả về HTML, bạn sẽ kết hợp chặt chẽ dữ liệu và bản trình bày của mình. Khi API trả về HTML, điều duy nhất bạn có thể làm (dễ dàng) với HTML đó là hiển thị nó dưới dạng một phần của trang lớn hơn. Từ một góc độ khác, điều duy nhất API phù hợp là cung cấp trang của bạn bằng HTML. Ngoài ra, bạn đã trải rộng HTML của mình trên cả mã máy khách và mã máy chủ. Điều này có thể làm cho bảo trì đau đầu.

Nếu API của bạn trả về JSON hoặc một số dạng dữ liệu thuần túy khác, nó sẽ trở nên hữu ích hơn nhiều. Ứng dụng hiện tại vẫn có thể sử dụng dữ liệu đó và trình bày nó một cách thích hợp. Bây giờ, mặc dù, những thứ khác có thể sử dụng API để truy cập cùng một dữ liệu. Một lần nữa, bảo trì cũng dễ dàng hơn - tất cả các HTML nằm ở một nơi, vì vậy nếu bạn muốn định kiểu lại toàn bộ trang web, bạn không cần phải thay đổi API.

HTML được gắn với một thiết kế cụ thể và sử dụng.

Với HTML, nếu bạn muốn thay đổi bố cục trang, bạn cần thay đổi cách html được tạo bởi lệnh gọi máy chủ. Thông thường, điều đó đòi hỏi một lập trình viên back-end. Bây giờ bạn có các lập trình viên back-end, theo định nghĩa không phải là người viết html tốt nhất của bạn, xử lý các cập nhật này.

Với JSON, nếu bố cục trang thay đổi, cuộc gọi máy chủ JSON hiện tại không nhất thiết phải thay đổi. Thay vào đó, nhà phát triển front-end của bạn, hoặc thậm chí là nhà thiết kế, cập nhật mẫu để tạo ra HTML khác nhau mà bạn muốn từ cùng một dữ liệu cơ bản.

Ngoài ra, JSON có thể trở thành nền tảng cho các dịch vụ khác. Bạn có thể có các vai trò khác nhau cần xem cùng một dữ liệu cơ bản theo những cách khác nhau. Ví dụ: bạn có thể có một trang web khách hàng hiển thị dữ liệu về sản phẩm trong trang đặt hàng và trang bán hàng bên trong cho các đại diện hiển thị cùng một dữ liệu theo bố cục rất khác nhau, có thể bên cạnh một số thông tin khác không có sẵn cho khách hàng nói chung. Với JSON, cùng một cuộc gọi máy chủ có thể được sử dụng trong cả hai chế độ xem.

Cuối cùng, JSON có thể mở rộng tốt hơn. Trong những năm gần đây, chúng tôi đã quá nhiệt tình với các khung javascript phía máy khách. Tôi nghĩ rằng đã đến lúc phải thực sự lùi một bước và bắt đầu suy nghĩ về những gì javascript chúng ta đang sử dụng và cách nó ảnh hưởng đến hiệu suất trình duyệt ... đặc biệt là trên các thiết bị di động. Điều đó nói rằng, nếu bạn đang chạy một trang web đủ lớn để yêu cầu cụm máy chủ hoặc cụm máy chủ, thay vì một máy chủ, JSON có thể mở rộng tốt hơn. Người dùng sẽ cung cấp cho bạn thời gian xử lý miễn phí trong trình duyệt của họ và nếu bạn tận dụng lợi thế đó, bạn có thể giảm tải máy chủ trong một triển khai lớn. JSON cũng sử dụng ít băng thông hơn, vì vậy, một lần nữa, nếu bạn đủ lớnvà sử dụng nó một cách thích hợp, JSON rẻ hơn đáng kể. Tất nhiên, nó cũng có thể mở rộng quy mô tồi tệ hơn, nếu bạn kết thúc việc cung cấp các thư viện 40KB để phân tích 2KB dữ liệu thành 7KB của html, vì vậy, một lần nữa: bạn phải trả tiền để biết bạn đang làm gì. Nhưng tiềm năng là có cho JSON để cải thiện hiệu suất và chi phí.

Không có gì sai với điểm cuối như vậy nếu nó đáp ứng các yêu cầu của nó. Nếu bắt buộc phải nhổ ra html mà một người tiêu dùng đã biết có thể phân tích hiệu quả, chắc chắn, tại sao không?

Vấn đề là, trong trường hợp chung, bạn muốn các điểm cuối của bạn phun ra một trọng tải được hình thành tốt và có khả năng phân tích cú pháp hiệu quả bởi một trình phân tích cú pháp tiêu chuẩn. Và bằng cách hiệu quả phân tích cú pháp, ý tôi là, phân tích cú pháp có thể khai báo.

Nếu khách hàng của bạn bị buộc phải đọc tải trọng và cạy các bit thông tin mở từ nó bằng các vòng lặp và câu lệnh if, thì nó không thể phân tích cú pháp một cách hiệu quả. Và HTML, theo cách của nó, nó rất được tha thứ trong việc không đòi hỏi bản thân phải được hình thành tốt.

Bây giờ, nếu bạn chắc chắn rằng html của bạn tuân thủ xml, thì bạn là vàng.

Như đã nói, tôi có một vấn đề quan trọng với điều này:

Tôi sẽ nói với bạn điều này: một điểm cuối trả về HTML làm giảm sự phụ thuộc của bạn vào các thư viện JavaScript và giảm tải cho trình duyệt người dùng vì không cần phải diễn giải / thực thi mã JS để tạo các đối tượng DOM - HTML đã có sẵn, đó chỉ là vấn đề phân tích các yếu tố và kết xuất chúng. Tất nhiên, điều này có nghĩa là chúng ta đang nói về một lượng dữ liệu hợp lý. 10 megabyte dữ liệu HTML không hợp lý.

Đó là một ý tưởng tồi cho dù bạn cắt nó như thế nào. Nhiều thập kỷ kinh nghiệm công nghiệp tập thể đã cho chúng ta thấy rằng, nói chung, nên tách dữ liệu (hoặc mô hình) khỏi màn hình (hoặc chế độ xem).

Ở đây bạn đang kết hợp cả hai với mục đích thực thi mã JS nhanh chóng. Và đó là một tối ưu hóa vi mô.

Tôi chưa bao giờ thấy đây là một ý tưởng hay ngoại trừ trong các hệ thống rất tầm thường.

Lời khuyên của tôi? Đừng làm điều đó. HC SVNT DRACONES , YMMV, v.v.

JSON chỉ là một bản trình bày văn bản của dữ liệu có cấu trúc. Một khách hàng tự nhiên cần phải có một trình phân tích cú pháp để xử lý dữ liệu nhưng hầu như tất cả các ngôn ngữ đều có các hàm phân tích cú pháp JSON. Sử dụng trình phân tích cú pháp JSON hiệu quả hơn nhiều so với sử dụng trình phân tích cú pháp HTML. Nó mất ít dấu chân. Không như vậy với trình phân tích cú pháp HTML.

Trong PHP, bạn chỉ cần sử dụng json_encode($data)và tùy thuộc vào máy khách ở phía bên kia để phân tích cú pháp. Và khi bạn tìm nạp dữ liệu JSON từ một dịch vụ web, bạn chỉ cần sử dụng $data=json_decode($response)và bạn có thể quyết định cách sử dụng dữ liệu như bạn sẽ làm với các biến.

Giả sử bạn phát triển một ứng dụng cho thiết bị di động, tại sao bạn cần định dạng HTML khi các ứng dụng di động hiếm khi sử dụng trình duyệt web để phân tích dữ liệu? Nhiều ứng dụng di động sử dụng JSON (định dạng phổ biến nhất) để trao đổi dữ liệu.

Xem xét rằng điện thoại di động thường nằm trên các kế hoạch có đồng hồ đo, tại sao bạn muốn sử dụng HTML chiếm nhiều băng thông hơn JSON?

Tại sao sử dụng HMTL khi HTML bị giới hạn về từ vựng và JSON có thể định nghĩa dữ liệu? {"person_name":"Jeff Doe"}có nhiều thông tin hơn HTML có thể cung cấp về dữ liệu của nó vì nó chỉ xác định cấu trúc cho trình phân tích cú pháp HTML, không xác định dữ liệu.

JSON không có gì để làm với HTTP. Bạn có thể đặt JSON trong một tệp. Bạn có thể sử dụng nó cho cấu hình. Nhà soạn nhạc sử dụng JSON. Bạn cũng có thể sử dụng nó để lưu các biến đơn giản vào các tệp.

Thật khó để phân loại đúng hay sai. IMO, những câu hỏi tôi sẽ hỏi là: " nó nên " hay " nó có thể làm với ít hơn không? ".

Mọi điểm cuối nên cố gắng truyền đạt với càng ít nội dung càng tốt. Tỷ lệ nhiễu tín hiệu thường là mã HTTP <JSON <XHTML. Trong hầu hết các tình huống, thật tốt khi chọn giao thức ít ồn nhất.

Tôi khác ở điểm về tải trình duyệt của máy khách bởi @machado, vì với các trình duyệt hiện đại thì đây không phải là vấn đề. Hầu hết trong số chúng được trang bị để xử lý mã HTTP và phản hồi JSON khá tốt. Và mặc dù bạn không có các thử nghiệm tại thời điểm này, việc bảo trì dài hạn một giao thức ít ồn hơn sẽ rẻ hơn so với giao thức trên nó.