JSON 대신 생성된 HTML을 반환하는 것이 나쁜 관행인 이유는 무엇입니까?아니면 그러한가?

JSON 대신 생성된 HTML을 반환하는 것이 나쁜 관행인 이유는 무엇입니까?아니면 그러한가?

JQuery 또는 기타 유사한 프레임워크를 사용하여 커스텀 URL/Web 서비스에서 HTML 콘텐츠를 쉽게 로드할 수 있습니다.지금까지도 여러 번 이 방법을 사용했지만, 퍼포먼스는 만족스러웠습니다.

하지만 모든 책들, 모든 전문가들이 HTML 대신 JSON을 사용하라고 하고 있습니다. HTML보다 훨씬 더 나은 방법은 무엇일까요?

그게 훨씬 더 빠릅니까?
서버의 부하가 매우 적습니까?

한편으로 생성된 HTML을 사용하는 이유가 있습니다.

1. 단순한 마크업으로 JSON만큼 콤팩트하거나 실제로 콤팩트한 경우가 많습니다.
2. 코드 없이 마크업만 할 수 있기 때문에 오류 발생률이 낮아집니다.
3. 클라이언트 측에서는 코드를 따로 쓸 필요가 없기 때문에 대부분의 경우 프로그래밍이 더 빠릅니다.

당신은 어느 편이고 그 이유는 무엇입니까?

사실 난 양쪽 다 좀 편해.

• javascript 측에서 필요한 것은 데이터일 경우 JSON을 사용합니다.
• 자바스크립트 쪽에서 필요한 것은 계산을 하지 않는 프레젠테이션일 경우 HTML을 주로 사용합니다.

HTML을 사용하는 주된 장점은 페이지 전체를 Ajax 요청에서 반환된 것으로 대체하고 싶을 때 입니다.

• JS에서 페이지 일부를 재구축하는 것은 (매우) 어렵다.
• 서버측에는 이미 템플릿엔진이 몇 개 있을 것입니다.이 엔진은 애초에 페이지를 생성하기 위해 사용되었습니다.왜 재사용하지 않는가?

적어도 서버에서는 일반적으로 '퍼포먼스' 측면은 고려하지 않습니다.

• 서버에서 HTML 또는 일부 JSON을 생성해도 큰 차이는 없습니다.
• 네트워크를 통과하는 데이터의 크기에 대해서: 음, 아마도 수백 KB/html의 데이터를 사용하지 않을 것입니다.전송하는 모든 것에 gzip을 사용하는 것이 가장 큰 차이점입니다(HTML과 JSON 중 하나를 선택하지 않음).
• 다만, 고려해야 할 것은, JSON 데이터로부터 HTML(또는 DOM 구조)을 재작성하기 위해서 클라이언트에 필요한 자원입니다.HTML 의 일부를 페이지에 밀어넣는 것과 비교한다;-)

마지막으로 가장 중요한 것이 하나 있습니다.

• JS가 HTML로 페이지에 데이터를 삽입하는 데 필요한 JSON + 코드로서 데이터를 전송하는 새로운 시스템을 개발하는 데 얼마나 걸립니까?
• HTML을 반환하는 데 얼마나 걸립니까?또, 기존의 서버측 코드 중 일부를 재사용할 수 있다면 얼마나 걸릴까요?

또 다른 답변을 드리자면 페이지의 여러 부분을 업데이트해야 할 경우 여러 HTML 부분을 그룹화하는 하나의 큰 문자열 안에 모든 부분을 전송하고 관련 부분을 JS에서 추출하는 솔루션/해킹이 있습니다.

예를 들어 다음과 같은 문자열을 반환할 수 있습니다.

<!-- MARKER_BEGIN_PART1 -->
here goes the html
code for part 1
<!-- MARKER_END_PART1 -->
<!-- MARKER_BEGIN_PART2 -->
here goes the html
code for part 2
<!-- MARKER_END_PART2 -->
<!-- MARKER_BEGIN_PART3 -->
here goes the json data
that will be used to build part 3
from the JS code
<!-- MARKER_END_PART3 -->

별로 좋아 보이지 않지만, 확실히 도움이 됩니다(HTML 데이터가 너무 커서 JSON에 캡슐화되지 않을 때) : 프레젠테이션이 필요한 페이지의 일부를 HTML로 전송하고 데이터가 필요한 상황을 위해 JSON을 전송합니다.

...그리고 그것들을 추출하기 위해서는 JS 서브스트링 메서드가 효과가 있을 것입니다;-)

저는 주로 여기에 기재된 의견에 동의합니다.다음과 같이 요약하고 싶습니다.

• HTML 을 클라이언트측에서 해석해, HTML 에 관한 계산을 실시하게 되면, HTML 를 송신하는 것은 좋지 않습니다.

• 페이지의 DOM 트리에 JSON을 통합하기만 하면 JSON을 전송하는 것은 잘못된 방법입니다.

음.

저는 이런 식으로 사물을 분리하는 것을 좋아하는 드문 사람 중 한 명입니다.- 서버는 데이터(모델)의 전달을 담당합니다.- 클라이언트는 데이터(모델)의 표시와 조작을 담당합니다.

따라서 서버는 모델 제공에 주력해야 합니다(이 경우 JSON이 더 좋습니다).이렇게 하면 유연한 접근을 할 수 있습니다.모델 뷰를 변경하려면 서버가 동일한 데이터를 전송하도록 하고 해당 데이터를 뷰로 변경하는 클라이언트인 javascript 컴포넌트를 변경하기만 하면 됩니다.서버가 데스크톱 애플리케이션뿐만 아니라 모바일 디바이스에도 데이터를 전송한다고 가정해 보십시오.

또, 이 어프로치는, 서버와 클라이언트 코드를 동시에 구축할 수 있기 때문에, js로부터 PHP/JAVA 등으로 계속 전환할 때 발생하는, 초점을 잃지 않고 생산성을 향상시킵니다.

일반적으로 대부분의 사람들은 js를 마스터하지 않기 때문에 서버 측에서 가능한 한 많이 하는 것을 선호하기 때문에 가급적 피하려고 합니다.

기본적으로, 앵글을 다루는 사람들과 같은 의견입니다.그것이 웹 앱의 미래라고 생각합니다.

덧붙이고 싶은 흥미로운 것이 있습니다.저는 한 번만 전체 뷰를 불러오는 앱을 개발했습니다.이 시점부터 서버와의 통신은 ajax만을 사용하여 이루어집니다.한 페이지만 로드하면 됩니다(이 이유는 여기서 중요하지 않습니다).흥미로운 점은 Javascript에서 조작할 데이터와 표시해야 할 부분적인 데이터를 특별히 반환해야 한다는 것입니다.나는 이것을 두 개의 다른 액션 방법으로 두 개의 콜로 나눌 수 있었지만, 나는 조금 더 재미있는 것을 하기로 결정했다.

확인해 주세요.

public JsonResult MyJsonObject(string someData)
{
     return Json(new { SomeData = someData, PartialView = RenderPartialViewToString("JsonPartialView", null) }, JsonRequestBehavior.AllowGet);
}

Render Partial View To String()은 어떤 것입니까?바로 여기에 작은 쿨링 덩어리가 있습니다.

protected string RenderPartialViewToString(string viewName, object model)
{
     ViewData.Model = model;

     using (StringWriter sw = new StringWriter())
     {
          ViewEngineResult viewResult = ViewEngines.Engines.FindPartialView(ControllerContext, viewName);
          ViewContext viewContext = new ViewContext(ControllerContext, viewResult.View, ViewData, TempData, sw);
          viewResult.View.Render(viewContext, sw);

          return sw.GetStringBuilder().ToString();
     }
}

퍼포먼스 테스트를 실시하지 않았기 때문에 JsonResult와 ParticalViewResult에 대해 각각1개의 액션 메서드를 호출하는 것과 같은 오버헤드가 발생하는지 아닌지는 잘 모르겠습니다만, 그래도 꽤 훌륭하다고 생각했습니다.부분 보기를 문자열로 직렬화하고 Json과 함께 매개 변수 중 하나로 전송합니다.그런 다음 JQuery를 사용하여 해당 파라미터를 적절한 DOM 노드에 슬랩합니다.

내 하이브리드에 대해 어떻게 생각하는지 알려줘!

클라이언트측 처리가 필요없는 응답이라면 HTML이 좋다고 생각합니다.JSON을 송신하면, 그 클라이언트측의 처리만이 강제됩니다.

한편, 저는 모든 응답 데이터를 한꺼번에 사용하고 싶지 않을 때는 JSON을 사용하고 있습니다.예를 들어, 일련의 연쇄 선택 항목이 있으며, 여기서 선택한 값 1에 따라 두 번째 값을 채우는 데 사용할 값이 결정됩니다.

IMV는 데이터 표시에서 데이터를 분리하는 것입니다만, 저는 Pascal에 찬성합니다.따라서 클라이언트와 서버의 경계에서만 분리할 수 있다고는 할 수 없습니다.이미 (서버에) 이러한 분리가 있어 클라이언트에 무언가를 보여주고 싶은 경우, JSON을 되돌려 클라이언트로 후처리하거나 HTML을 돌려보내는 것은 전적으로 사용자의 요구에 달려 있습니다.일반적인 경우 HTML을 돌려보내는 것이 잘못되었다고 말하는 것은 IMV를 지나치게 포괄하는 것입니다.

JSON은 매우 용이한 경량 포맷입니다.클라이언트 측 템플릿 파서 데이터로 사용하기 시작하면서 그 아름다움을 알게 되었습니다.설명을 드리자면, 이전에는 smarty와 뷰를 서버 측에서 사용했지만(서버 부하가 높아짐), 현재는 커스텀 jquery 함수를 사용하고 있으며, 모든 데이터는 클라이언트 브라우저를 템플릿 파서로 사용하여 클라이언트 측에서 렌더링되고 있습니다.서버 리소스를 절약하고 브라우저는 매일 JS 엔진을 개선합니다.따라서 클라이언트의 해석 속도는 현시점에서는 중요하지 않습니다.또한 JSON 오브젝트는 일반적으로 매우 작기 때문에 클라이언트 측 자원을 많이 소비하지 않습니다.서버 부하가 매우 높기 때문에 모든 사용자에게 느린 사이트보다 느린 브라우저를 사용하는 일부 사용자에게는 느린 웹 사이트를 사용하는 것이 좋습니다.

한편, 서버로부터 순수 데이터를 송신하면, 프레젠테이션으로부터 데이터를 추출할 수 있기 때문에, 내일 데이터를 변경하거나 다른 서비스에 통합하고 싶은 경우는, 훨씬 간단하게 실시할 수 있습니다.

내 2센트만.

베스트 프랙티스라고 생각되는 클린 디커플링 클라이언트를 원한다면 100%의 DOM을 javascript에 의해 작성하는 것이 타당합니다.UI를 구축하는 방법을 모두 알고 있는 MVC 기반 클라이언트를 구축하면 사용자는 한 번 자바스크립트 파일을 다운로드하여 클라이언트에 캐시합니다.초기 로드 후의 모든 요청은 Ajax 기반이며 데이터만 반환합니다.이 접근방식은 지금까지 발견된 것 중 가장 깨끗하며 프레젠테이션의 깨끗한 독립 캡슐화를 제공합니다.

서버 측은 데이터 제공에만 집중합니다.

따라서 내일 제품에서 페이지 디자인을 완전히 변경하도록 요구받았을 때 변경되는 것은 DOM을 생성하는 소스 JS뿐이지만 기존 이벤트 핸들러를 재사용할 가능성이 높고 서버는 프레젠테이션에서 100% 분리되었기 때문에 인식하지 못합니다.

UI에 따라 DOM에서 두 개 이상의 다른 요소를 업데이트해야 할 수 있습니다.만약 당신의 답변이 HTML로 되어 있다면, 당신은 그것을 해석하여 무엇이 어디로 가는지 알 수 있습니까?또는 JSON 해시를 사용할 수도 있습니다.

조합하여 html 데이터를 포함한 JSON을 반환할 수도 있습니다.

{ 'dom_ele_1' : '<p>My HTML part 1</p>', 'dome_ele_2' : '<div>Your payment has been received</div>' }

HTML에는 태그, 스타일시트 등 표시되지 않고 중복된 데이터가 많이 있습니다.따라서 HTML 사이즈가 JSON 데이터에 비해 커지기 때문에 다운로드 및 렌더링 시간이 길어지고 브라우저가 새로운 데이터 렌더링에 바빠집니다.

json 전송은 일반적으로 javascript 위젯을 사용하여 목록이나 트리 뷰, 자동 완성 등의 정보를 서버에 요청하면 이루어집니다.JSON은 해석해서 raw로 사용하는 데이터이기 때문에 보내드립니다.그러나 HTML을 표시하기만 하면 서버 측에서 생성하고 브라우저에 표시하는 작업이 훨씬 줄어듭니다.브라우저는 내부가 있는 돔에 HTML을 직접 삽입하도록 최적화되어 있습니다.HTML = " "그래서 틀리지 않습니다.

디자인의 구조에 따라 다르다고 생각합니다만, HTML보다 JSON을 사용하는 것이 더 섹시할 뿐입니다만, 문제는 어떻게 하면 쉽게 관리할 수 있을까 하는 것입니다.

예를 들어, 사이트 전체의 동일한 html/style을 사용하는 리스트 페이지가 있다고 가정하면, 저는 글로벌 함수를 작성하여 HTML의 그 부분을 포맷하고 JSON 객체를 함수에 전달하기만 하면 됩니다.

클라이언트 측에서 계산을 수행할 필요가 없는 한 대부분의 경우 HTML 응답으로 충분합니다.

상황에 따라 다르죠

때때로 JSON을 피하는 것이 필수적입니다.예를 들어 프로그래머가 js 프로그래밍에 문제가 있을 때.

제 경험상으로는 인라인 JSON보다 Ajax 서비스를 더 잘 사용하세요.

조만간 js가 문제가 됩니다.

언급URL : https://stackoverflow.com/questions/1284381/why-is-it-a-bad-practice-to-return-generated-html-instead-of-json-or-is-it