JSON 데이터가 아닌 HTML을 반환하는 엔드 포인트에서 실제로 무엇이 문제입니까?

처음으로 PHP를 배우기 시작했을 때 (약 5-6 년 전) Ajax 에 대해 배웠고 "단계"를 밟았습니다.

1. 서버는 HTML 데이터를 반환하고 DOM의 innerHTML에 넣습니다.
2. XML과 같은 데이터 전송 형식에 대해 배우고 JSON을 사용합니다.
3. 바닐라 JavaScript 코드를 사용하여 JSON을 반환하고 UI를 빌드합니다.
4. jQuery로 이동
5. API, 헤더, HTTP 상태 코드, REST , CORS 및 부트 스트랩에 대해 학습합니다.
6. 당신은 배울 SPA 및 프론트 엔드 프레임 워크 ( 반작용 , Vue.js을 하고, AngularJS와 )과 JSON의 API 표준을.
7. 일부 엔터프라이즈 레거시 코드를 수신 한 후 검사하면 1 단계에 설명 된 작업을 수행합니다.

이 레거시 코드베이스로 작업하면서 HTML을 반환 할 수 있다고 생각조차하지 않았기 때문에 (지금은 전문가입니까?) 데이터를 반환하는 JSON 끝점을 찾는 데 어려움을 겪었습니다. Ajax 호출이 채워집니다. "프로그래머"에게 HTML을 반환하고 innerHTML을 사용하여 DOM에 직접 추가한다고 말했다.

물론 이것은 받아들이 기 어려웠다. JSON 엔드 포인트로 리팩토링하는 방법, 엔드 포인트의 단위 테스트 등에 대한 생각을 시작했습니다. 그러나이 코드베이스에는 테스트가 없습니다. 하나도 아닙니다. 그리고 그것은 200k 라인 이상입니다. 물론 내 작업 중 하나에는 전체 테스트를위한 접근 방법을 제안하는 것이 포함되지만 현재로서는 아직 다루지 않고 있습니다.

테스트가 없다면 "재사용이 불가능"하기 때문에이 JSON 엔드 포인트를 생성 할 특별한 이유가 없습니다. 문자 그대로 해당 부분에만 맞는 데이터를 반환합니다. 응용 프로그램이지만 HTML 데이터를 반환하므로 이미 암시 적이라고 생각합니다.

이 작업에서 정확히 무엇이 잘못 되었습니까?

JSON 데이터가 아닌 HTML을 반환하는 엔드 포인트에서 실제로 무엇이 문제입니까?

아무것도 아니에요 응용 프로그램마다 요구 사항이 다르므로 응용 프로그램이 SPA가 아니도록 설계되었을 수도 있습니다.

여러분이 인용 한이 아름다운 프레임 워크 (Angular, Vue, React 등)는 개발 시점에 사용 가능하지 않았거나 조직에서 사용할 "엔터프라이즈"항목이 아니었을 수 있습니다.

HTML을 반환하는 엔드 포인트는 JavaScript 라이브러리에 대한 종속성을 줄이고 DOM 객체를 만들기 위해 JS 코드를 해석 / 실행할 필요가 없기 때문에 사용자 브라우저의로드를 줄입니다. HTML은 이미 존재합니다. 요소를 파싱하고 렌더링하는 것입니다. 물론 이것은 합리적인 양의 데이터에 대해 이야기하고 있음을 의미합니다. 10MB의 HTML 데이터는 합리적이지 않습니다.

그러나 HTML을 반환하는 데 아무런 문제가 없으므로 JSON / XML을 사용하지 않으면 손실되는 것은 기본적으로 엔드 포인트를 API로 사용할 수 있다는 것입니다. 그리고 가장 큰 문제는 다음과 같습니다. 실제로 API 여야합니까?

관련 : JSON API에서 HTML을 반환해도 괜찮습니까?

JSON과 HTML은 서로 다른 두 가지 시맨틱 목적을 수행합니다.

데이터로 웹 페이지를 채우는 경우 JSON을 사용하십시오. 웹 페이지의 일부에서 웹 페이지를 작성하는 경우 HTML을 사용하십시오.

그들은 똑같은 것처럼 들릴지 모르지만 전혀 그렇지 않습니다. 우선, 서버에서 리턴 한 HTML을 사용하여 웹 페이지의 일부를 빌드 할 때 서버 측에서 작업하는 것 입니다. 웹 페이지에 데이터를 바인딩 할 때는 클라이언트 측에서 작업하는 것 입니다.

또한 특정 페이지에 단단히 바인딩되지 않도록 HTML에주의해야합니다. 이런 방식으로 부분 페이지를 렌더링하는 요점은 부분을 재사용 할 수 있고 부분을 너무 구체적으로 만들면 다른 페이지로 구성되지 않습니다. JSON은 웹 페이지 구조가 아닌 데이터 일 뿐이 므로이 문제가 없습니다.

주요 문제는 서버가 HTML 구조를 알아야하는 클라이언트와 밀접하게 연결되어 있다는 것입니다. 또한 새로운 방식이나 새로운 애플리케이션에서 엔드 포인트를 재사용하기가 더 어려워집니다.

일반 데이터를 반환하고 클라이언트가 렌더링하도록하면 커플 링이 줄어들고 유연성과 테스트 가능성이 높아집니다. 클라이언트에서 모의 ​​데이터에 대한 단위 테스트를 실행하고 서버에서 단위 테스트를 실행하여 원하는 데이터를 테스트 할 수 있습니다.

나는 당신이 조금 뒤로 가지고 있다고 생각합니다. 당신은 말한다 :

우리는 어떤 테스트도하지 않으므로이 JSON 끝점을 만들 특별한 이유가 없습니다.

적절한 엔드 포인트를 사용하는 이유 는 테스트 할 수 있기 때문입니다. 테스트를하지 않는 것이 테스트를 시작하기에 좋은 이유라고 말하고 싶습니다. 즉, 테스트하기에 적합한 로직이있는 경우입니다.

200k 줄의 코드는 리팩토링하기가 많고 유지 관리가 어려울 수 있습니다. 일부 엔드 포인트를 분석하고 테스트하는 것이 좋은 시작점이 될 수 있습니다.

또 다른 이유는 서버를 클라이언트와 분리하는 것입니다. 먼 미래에 응용 프로그램 디자인이나 레이아웃이 변경되면 HTML 출력보다 적절한 데이터 형식으로 작업하기가 더 쉽습니다. 이상적인 세상에서는 클라이언트를 변경하고 서버를 전혀 만지지 않아도됩니다.

웹 페이지를 구축하는 방법에는 3 가지가 있습니다 (적어도?).

• 전체 페이지 서버 측을 생성하십시오.
• 서버 플러스 코드 (JavaScript)에서 베어 본 페이지를 반환하고 페이지가 데이터를 가져와 HTML 클라이언트 측으로 렌더링하도록합니다.
• 부분 페이지와 코드를 반환하고 코드가 페이지에 놓을 수있는 미리 렌더링 된 HTML 블록을 가져 오도록합니다.

첫 번째는 괜찮습니다. 두 번째도 괜찮습니다. 문제가 마지막입니다.

그 이유는 간단합니다. 이제 HTML 페이지 구성을 완전히 분리 된 부분으로 나누었 습니다. 문제는 유지 보수 중 하나입니다. 이제 UI 세부 사항 관리를 담당하는 두 개의 개별 엔티티가 있습니다. 따라서 CSS와 다른 유사한 세부 사항을 두 개의 개별 조각간에 동기화 상태로 유지해야합니다. 사이드 바의 너비를 변경 했습니까? 큰. 이제 다시 나타나는 HTML 조각은 세로 막대 너비에 대한 가정이 더 이상 유지되지 않으므로 가로 스크롤이 발생합니다. 해당 블록의 배경색을 변경 했습니까? HTML 조각의 글꼴 색이 다른 배경색으로 가정되어 누군가가 해당 끝점을 테스트하지 않았기 때문에 충돌합니다.

요점은 이제 단일 위치 (즉, 프리젠 테이션 논리)에 집중해야하는 지식을 분할 한 것이므로 모든 조각이 올바르게 맞춰지기가 더 어려워집니다. JSON API를 사용하면 모든 로직을 프런트 엔드에 그대로 유지하거나 데이터를 HTML로 렌더링하여 시작하는 경우 서버 측 템플릿에 모두 유지할 수 있습니다. 프리젠 테이션 지식 / 논리를 한 곳에 보관하여 일관되고 단일 프로세스의 일부로 관리 할 수 ​​있습니다. HTML / CSS / JS는 많은 작은 조각으로 나뉘 지 않고 똑바로 유지하기가 어렵습니다.

JSON API는 또한 프리젠 테이션 로직과 완전히 독립적으로 데이터를 사용할 수 있다는 이점이 있습니다. 이를 통해 모바일 앱 및 웹 페이지와 같은 여러 다른 발표자가 동일한 데이터를 사용할 수 있습니다. 특히 브라우저없이 데이터를 사용할 수 있습니다 (예 : 모바일 앱 또는 야간 크론 작업). 이러한 소비자는 HTML을 구문 분석하지 못할 수도 있습니다. (물론 이것은 다른 소비자간에 데이터가 동일하거나 다른 소비자의 하위 집합을 사용할 수있는 상황에 의존해야합니다.)이 기능이 필요한지 여부는 프레젠테이션을 관리하는 동안 특정 응용 프로그램의 요구 사항에 따라 다릅니다. 상관없이 논리가 필요합니다. 그러나 만약 당신이 그것을 사전에 구현한다면, 당신은 미래 성장을 위해 더 잘 준비 될 것이라고 말할 것입니다.

서버가 HTML 조각을 반환하고 UI가 일부 요소의 .innerHTML에 할당하는 데 아무런 문제가 없다고 말하고 싶습니다. 이것은 제 생각에 비동기 JavaScript 코드를 개발하는 가장 쉬운 방법입니다. JavaScript를 사용하여 가능한 한 적은 작업을 수행하고 제어 된 백엔드 환경에서 가능한 많은 작업을 수행 할 수 있다는 이점이 있습니다. 브라우저에서의 JavaScript 지원은 다양하지만 백엔드에는 항상 동일한 버전의 백엔드 구성 요소가 있으므로 백엔드에서 최대한 많은 작업을 수행하면 버전 비 호환성이 최소화됩니다.

이제 때로는 단순한 HTML 조각 이상의 것을 원할 수도 있습니다. 예를 들어, 상태 코드 및 HTML 조각입니다. 그런 다음 statusCode와 HTML의 두 멤버가있는 JSON 객체를 사용할 수 있습니다. statusCode와 HTML의 두 번째 멤버는 statusCode를 확인한 후 일부 요소의 .innerHTML에 지정할 수 있습니다. 따라서 JSON을 사용하고 innerHTML을 사용하는 것이 결코 대안적인 독점적 접근법이 아닙니다. 그들은 함께 사용될 수 있습니다.

JSON을 사용하면 동일한 응답으로 여러 요소의 .innerHTML에 지정된 여러 개의 HTML 조각을 가질 수도 있습니다.

요약하면 : .innerHTML을 사용하십시오. 코드가 가능한 많은 브라우저 버전과 호환됩니다. 더 필요한 경우 JSON과 .innerHTML을 함께 사용하십시오. XML을 피하십시오.

원칙적으로 잘못된 것은 없습니다 . 문제는 무엇을 달성하고 싶습니까?

JSON은 데이터 전송에 적합합니다. HTML을 대신 보내고 클라이언트가 HTML에서 데이터를 추출 할 것을 기대한다면 그것은 쓰레기입니다.

당신이 다른 한편, 만약 원하는 HTML로 렌더링 될 것입니다 HMTL를 전송 한 후 HTML 파일로 보내 - 대신 문자열로 HTML을 포장 JSON으로 문자열을 돌려, JSON을 전송, 다른 측면에서 그것을 디코딩 , 문자열을 가져오고 문자열에서 HTML을 추출합니다.

그리고 어제 나는 배열에 두 개의 항목을 넣고 배열을 JSON으로 바꾸고 JSON을 문자열 안에 넣고 문자열을 배열 안에 넣고 전체 배열을 JSON으로 바꾸어 클라이언트로 보낸 코드를 보았습니다. JSON은 문자열을 포함하는 배열을 가져 와서 문자열을 가져 와서 문자열에서 JSON을 추출하고 JSON을 디코딩 한 다음 두 항목이있는 배열을 얻었습니다. 하지마

이 모든 것은 API의 목적에 달려 있지만 일반적으로 설명하는 것은 우려 의 분리를 매우 강력하게 위반 하는 것입니다 .

최신 애플리케이션에서 API 코드는 데이터를 담당하고 클라이언트 코드는 프리젠 테이션을 담당해야합니다.

API가 HTML을 반환하면 데이터와 프레젠테이션이 밀접하게 결합 된 것입니다. API가 HTML을 반환하면 해당 HTML로 (쉽게) 수행 할 수있는 유일한 작업은 더 큰 페이지의 일부로 HTML을 표시하는 것입니다. 다른 각도에서 API가 유용한 유일한 것은 페이지에 HTML을 제공하는 것입니다. 또한 클라이언트와 서버 코드 모두에 HTML을 배포했습니다. 이로 인해 유지 관리가 어려워 질 수 있습니다.

API가 JSON 또는 다른 형태의 순수한 데이터를 반환하면 훨씬 유용합니다. 기존 앱은 여전히 ​​해당 데이터를 소비하여 적절하게 제시 할 수 있습니다. 그러나 이제 다른 것들은 API를 사용하여 동일한 데이터에 액세스 할 수 있습니다. 모든 HTML이 한 곳에 상주하므로 전체 사이트를 다시 스타일링하려면 API를 변경할 필요가 없습니다.

HTML은 특정 디자인 및 사용과 관련이 있습니다.

HTML을 사용하여 페이지 레이아웃을 변경하려면 서버 호출에서 HTML이 생성되는 방식을 변경해야합니다. 일반적으로 백엔드 프로그래머가 필요합니다. 이제 여러분은 백엔드 프로그래머가 있습니다.이 프로그래머는 정의상 최고의 HTML 작성자가 아닌 이러한 업데이트를 처리합니다.

JSON을 사용하면 페이지 레이아웃이 변경되면 기존 JSON 서버 호출을 전혀 변경할 필요가 없습니다. 대신 프런트 엔드 개발자 또는 디자이너가 동일한 기본 데이터에서 원하는 다른 HTML을 생성하도록 템플릿을 업데이트합니다.

또한 JSON은 다른 서비스의 기초가 될 수 있습니다. 다른 방법으로 동일한 기본 데이터를보아야하는 다른 역할이있을 수 있습니다. 예를 들어, 주문 페이지에 제품에 대한 데이터를 표시하는 고객 웹 사이트와 일반 고객이 사용할 수없는 다른 정보와 함께 매우 다른 레이아웃으로 동일한 데이터를 표시하는 담당자의 내부 판매 페이지가있을 수 있습니다. JSON을 사용하면 두 서버 모두에서 동일한 서버 호출을 사용할 수 있습니다.

마지막으로 JSON은 확장 성이 더 좋습니다. 최근 몇 년간 우리는 클라이언트 측 자바 스크립트 프레임 워크를 사용했습니다. 실제로 한 걸음 물러서서 우리가 사용하는 자바 스크립트와 브라우저 성능에 미치는 영향, 특히 모바일 장치에 대해 생각하기 시작할 때입니다. 즉, 단일 서버 대신 서버 팜 또는 클러스터가 필요할 정도로 큰 사이트를 실행하는 경우 JSON을 확장 할 수 있습니다. 사용자는 브라우저에서 처리 시간을 무료로 제공 할 수 있으며,이를 활용하면 대규모 배포에서 서버로드를 줄일 수 있습니다. JSON은 또한 더 적은 대역폭을 사용하므로 충분히 큰 경우 다시적절하게 사용하면 JSON이 훨씬 저렴합니다. 물론 2KB의 데이터를 7KB의 html로 구문 분석하기 위해 40KB 라이브러리를 공급하면 다시 확장 할 수 있습니다. 그러나 JSON이 성능과 비용을 향상시킬 수 있는 잠재력 이 있습니다.

그러한 엔드 포인트가 요구 사항을 충족시키는 경우 아무런 문제가 없습니다. 알려진 소비자가 효과적으로 구문 분석 할 수있는 HTML을 추출해야한다면 왜 그렇지 않습니까?

문제는 일반적인 경우 엔드 포인트가 표준 구문 분석기에 의해 올바르게 구성되고 효과적으로 구문 분석 할 수있는 페이로드를 내뱉기를 원한다는 것입니다. 그리고 효과적으로 파싱 할 수 있다는 것은 선언적으로 파싱 할 수 있다는 것을 의미합니다.

클라이언트가 페이로드를 읽고 루프와 if 문을 사용하여 열린 정보 비트를 들어 올리면 효과적으로 구문 분석 할 수 없습니다. 그리고 HTML은 그 자체이기 때문에 스스로 구성해야 할 필요가 없기 때문에 매우 용서됩니다.

이제 HTML이 XML을 준수하는지 확인하면 금입니다.

그 말에 따르면, 나는 이것에 심각한 문제가 있습니다.

HTML을 반환하는 엔드 포인트는 JavaScript 라이브러리에 대한 종속성을 줄이고 DOM 객체를 만들기 위해 JS 코드를 해석 / 실행할 필요가 없기 때문에 사용자 브라우저의로드를 줄입니다. HTML은 이미 존재합니다. 요소를 파싱하고 렌더링하는 것입니다. 물론 이것은 합리적인 양의 데이터에 대해 이야기하고 있음을 의미합니다. 10MB의 HTML 데이터는 합리적이지 않습니다.

어떻게 잘라도 나쁜 생각입니다. 수십 년간의 산업 경험을 통해 일반적으로 데이터 (또는 모델)와 디스플레이 (또는 뷰)를 분리하는 것이 좋습니다.

여기에서는 빠른 JS 코드 실행을 위해 두 가지를 병합합니다. 그리고 그것은 미세 최적화입니다.

나는 아주 사소한 시스템을 제외하고는 이것을 좋은 아이디어로 본 적이 없다.

내 조언? 하지마 HC SVNT DRACONES , YMMV 등

JSON은 구조화 된 데이터를 텍스트로 표현한 것입니다. 클라이언트는 당연히 데이터를 처리하기 위해 파서를 가져야하지만 사실상 모든 언어에는 JSON 파서 기능이 있습니다. HTML 파서를 사용하는 것보다 JSON 파서를 사용하는 것이 훨씬 더 효율적입니다. 발자국이 거의 없습니다. HTML 파서는 그렇지 않습니다.

PHP에서는 그냥 사용 json_encode($data)하고 파싱하는 것은 다른 쪽의 클라이언트에게 달려 있습니다. 그리고 웹 서비스에서 JSON 데이터를 가져올 때는 $data=json_decode($response)변수를 사용하는 것처럼 데이터를 사용하는 방법을 결정할 수 있습니다.

모바일 장치 용 앱을 개발한다고 가정 해보십시오. 모바일 앱이 웹 브라우저를 사용하여 데이터를 구문 분석하는 경우가 거의없는 경우 왜 HTML 형식이 필요합니까? 많은 모바일 앱은 JSON (가장 일반적인 형식)을 사용하여 데이터를 교환합니다.

모바일이 종종 요금제를 사용한다는 점을 고려할 때 왜 JSON보다 훨씬 더 많은 대역폭을 차지하는 HTML을 사용하고 싶습니까?

HTML이 어휘가 제한되어 있고 JSON이 데이터를 정의 할 수있는 경우 HMTL을 사용하는 이유는 무엇입니까? {"person_name":"Jeff Doe"}데이터를 정의하지 않고 HTML 파서의 구조 만 정의하므로 HTML이 데이터에 대해 제공 할 수있는 것보다 더 유익합니다.

JSON은 HTTP와 관련이 없습니다. JSON을 파일에 넣을 수 있습니다. 구성에 사용할 수 있습니다. Composer는 JSON을 사용합니다. 이를 사용하여 간단한 변수를 파일에 저장할 수도 있습니다.

옳고 그름을 분류하기는 어렵습니다. IMO, 내가 물을 질문은 " 해야한다 "또는 " 덜 할 수 있는가? "입니다.

모든 엔드 포인트는 가능한 적은 컨텐츠와 통신하기 위해 노력해야합니다. 신호 대 잡음비는 일반적으로 HTTP 코드 <JSON <XHTML입니다. 대부분의 상황에서 가장 시끄러운 프로토콜을 선택하는 것이 좋습니다.

최신 브라우저에서는 문제가되지 않으므로 @machado의 클라이언트 브라우저로드에 대한 요점이 다릅니다. 대부분은 HTTP 코드와 JSON 응답을 잘 처리합니다. 현재로서는 테스트가 없지만 노이즈가 적은 프로토콜을 장기간 유지 관리하는 것이 위의 것보다 저렴합니다.