MVC 및 RESTful API 서비스

MVC는 매우 간단합니다. 모델, 컨트롤러 및 뷰가 있습니다. 웹 사이트를 만들 때 ' client가 REST 키워드 요청을 서버로 전송-> 서버가 요청한 URL을 컨트롤러 작업과 일치-> 데이터 수집 / 처리를 위해 모델을 호출하여 결과를 얻음 으로써 모든 웹 사이트가 함께 제공됩니다. -> 결과를 ​​HTML 페이지 (보기) ' 로 클라이언트에 다시 반환합니다 .

순수한 RESTful API 웹 서비스에 대해 이야기하고 있다면 어떨까요? 그런 다음 ' client 와 같은 흐름은 서버에 REST 키워드 요청을 보냅니다-> 서버는 요청 된 URL을 컨트롤러 작업에 일치시킵니다-> 데이터 수집 / 처리를위한 모델을 호출하고 결과를 얻습니다-> 결과는 JSON으로 클라이언트에 다시 반환됩니다 . 이전과 동일하지만 '보기'가 없거나 생성 된 JSON을 '보기'로 생각할 수 있습니다. 어떤 의미에서 우리는 MVC의 MC 부분 만 사용하고 있습니다. 그렇게해야합니까? 아니면 MVC 대신 API 전용 서비스에 더 적합한 다른 패턴이 있습니까?

MVC는 객체 지향 시스템이 UI를 가질 수있는 방법에 관한 Smalltalk 세계의 패러다임입니다.

초기 웹 프레임 워크는 일반적인 개념 (비즈니스 로직 분리, 로직 제어 및 뷰 로직)을 취하여 웹 애플리케이션을 구성하는 방식에 원칙을 적용했습니다. 이전에는 도메인 객체 내부의 HTML 생성 코드 또는 HTML 템플릿 내부의 비즈니스 로직을 매우 엉망으로 만드는 것이 드문 일이 아니 었습니다 (초기 PHP 생각)

스몰 토크 세계의 원래 MVC는 실제로 대부분의 웹 프레임 워크에서 MVC가 아닙니다. 스몰 토크가 UI 화면을 이해했다는 점에서 HTML 출력은 실제로 "보기"가 아닙니다.

이것이 MVC를 제대로 따르고 있는지에 너무 매달리지 않는 첫 번째 이유입니다. 거의 아무것도 없습니다. 우리의 HTML 템플릿이 비즈니스 로직으로 가득 차 있지 않다면 엄격한 부서로 줄이고 Hey에 대한 지침을 따르십시오 .

두 번째로 MVC는 서버 측 코드를 구성하는 방법입니다. REST / HTTP와는 아무런 관련이 없습니다. REST는 클라이언트와 서버가 통신하는 방법과 관련이 있습니다. 서버가 클라이언트에 보내는 표현이 템플릿 엔진으로 구성하는 데 많은 시간이 걸린 HTML 템플릿 또는 컨트롤러에서 한 번 호출 된 JSON 객체인지 여부는 중요하지 않습니다.

서버에 "보기"레이어가 필요하다고 생각하지 않는다면 괜찮습니다. 모든 컨트롤러가 일부 객체에서 JSON 파싱 호출을 호출하고 해당 데이터를 반환하더라도 특정 HTTP 요청을 처리하는 컨트롤러에서 비즈니스 로직 (예 : 모델)을 분리하면 여전히 이점을 얻을 수 있습니다.

보기는 응용 프로그램의 사용자 / 클라이언트가 해석 할 수있는 정보를 표시하는 계층입니다 (사용자가 실제 사람이어야한다는 것은 아닙니다). JSON은 뷰 레이어에 대해 완전히 유효한 형식이며 컴퓨터는이를 이해합니다.

뷰 레이어가 사용자가 응용 프로그램의 모델에 영향을주기 위해 사용할 수있는 정보를 게시하는 한 뷰의 모양은 중요하지 않습니다. 뷰는 여전히 사용자와 시스템 사이의 미들웨어 역할을하는 뷰입니다. .

MVC는 매우 간단합니다.

Martin Fowler는 아마도 이것에 동의하지 않을 것입니다 :

다른 장소에서 MVC에 대해 읽는 다른 사람들은 다른 아이디어를 취하여이를 'MVC'라고 설명합니다.

계속 ...

웹 사이트를 만들 때 '클라이언트가 REST 키워드 요청을 서버에 전송합니다-> 서버가 요청한 URL을 컨트롤러 작업에 일치시킵니다-> 데이터 수집 / 처리를 위해 모델을 호출하여 결과를 얻습니다. -> 결과를 ​​HTML 페이지 (보기)로 클라이언트에 다시 반환합니다. '

좋아, 이것은 약간 엉킴

MVC는 사용자 인터페이스를 구현하기위한 아이디어 모음입니다.

REST는 대규모 애플리케이션을 구축하기위한 아키텍처 제약 조건의 모음입니다.

여기서 말하는 웹은 동일한 제약 조건을 대부분 사용하여 구축 된 거대한 문서 관리 응용 프로그램입니다.

둘 사이에 나타나는 유사점은 잘못 선택되었거나 피상적입니다.

RESTafarians는 공통의 이해가 HATEOAS "응용 프로그램 상태의 엔진으로 하이퍼 텍스트"를, 그리고 알람 당신이 머리를 울리는 보내야합니다 - 왜 것 보기 의 엔진이 될 상태 ? 전제에 의문을 제기하고 추가 증거를 찾으면 두 가지 이상한 점을 발견 할 수도 있습니다.

먼저, 디스크에서 HTML을로드하여 HTTP 서버를 완전히 배제 할 수 있습니다. 브라우저는 이것으로 완벽하게 만족하며 기본 URL의 변경으로 인해 발생할 수있는 사소한 변형을 제외합니다. 모델과 컨트롤러에서 완전히 분리 된 뷰는 일반적으로 계속 작동하지 않습니다.

둘째, 최신 브라우저를주의 깊게 관찰하면 HTML에 대한 여러 뷰가 있음을 알 수 있습니다. 뷰에 대한 여러 뷰는 정말 이상한 생각처럼 보이지만 사용자 제스처에 응답하는 텍스트 마크 업이 포함 된 메인 프레젠테이션이 충분하다는 사실이 확실합니다. 그런 다음 "원본 뷰"항목이 생 HTML을 표시하고 응답합니다. 사용자 제스처. 거북은 끝이야!

물론 수수께끼에 대한 대답은 HTML이 시야가 아니라는 것입니다. 브라우저에서 위젯 콜렉션은보기이며 HTML을 읽음으로써 초기화 된 문서 오브젝트 모델 과 통신 합니다.

다시 말해, HTML은 Roy T. Fielding이 약속 한 것처럼 상태를 나타냅니다 .

순수한 RESTful API 웹 서비스에 대해 이야기하고 있다면 어떨까요? 이전과 동일하지만 '보기'가 없습니다.

더 정확하게는 이전과 동일합니다.보기가 없습니다. HTML과 마찬가지로 JSON도 프로세스 경계를 ​​넘나 드는 데 적합한 상태를 나타냅니다.

"DTO"또는 "메시지"를 생각하면 추론을 당할 가능성이 훨씬 줄어 듭니다.

그렇게해야합니까?

JSON을 뷰로 전달하거나 뷰 모델로 사용하여 뷰를 구성해도 패턴이 위반되지 않습니다.

현재 작업중 인 현재 응용 프로그램에서 동일한 아키텍처를 사용하고 있으며 매우 잘 작동합니다. 멋진 JS 프레임 워크와 함께 응답 성이 뛰어난 디자인을 만들 수 있습니다.

아니면 MVC 대신 API 전용 서비스에 더 적합한 다른 패턴이 있습니까?

솔직히 모르겠다. 하지만 내가 생각하는 당신이 API에 MVC 사용 여부가 중요하지 않습니다 것을. 편리하다고 생각되는 것을 사용하십시오. 웹 서비스에 대해 이야기 할 때 보안, 일관성, 가용성 등과 같이 고려해야 할 훨씬 더 중요한 측면 (MVC와 직접 관련이 없음)이 있습니다.