4818
2016-02-22 20:25:26
1
우선 REST는 설계 스타일이 맞음을 확실히 하고자 합니다.
" REST is an architectural style consisting of a coordinated set of architectural constraints applied to components, connectors, and data elements, within a distributed hypermedia system."
인용은 REST의 영문 위키피디아입니다.
REST는 단순히 인터페이스 의미하는 것은 아니지만, 인터페이스 설계 방식을 포함하고 있으며 REST 기반으로 작성된 인터페이스 역시 REST 입니다.
애초에 Roy Fielding라는 사람이 박사논문을 내면서 제시한 웹 기반 어플리케이션 제작 기법에서 시작했고, 현재까지도 REST는 HTTP 규격을 준수하는 인터페이스를 사용하는 걸 포함하고 있습니다. 다만 해당 측면만 보고 REST를 설계 기법이 아니라고 판단하면 안됩니다.
REST API는 (API 사용자가 보기에) REST를 만족하게끔 설계, 구현되었다는 걸 기대하고 사용할 수 있는 API가 되겠죠.
흔히들 사용하는 RESTful API는 REST가 추구하는 스타일을 제대로 지켜서 만든 서비스의 인터페이스(API) 라고 보고요.
그리고 REST의 기본 원칙 중 하나가, REST를 기반으로 잘 구성된 인터페이스 설계는 인터페이스만 지킨다면 클라이언트와 서버가 독립적으로 개발, 개량이 가능하다는 것이고 이런 측면에서 서버, 클라이언트를 분리하여 작업할수 있다는 것입니다.
그리고 비즈니스 로직은 최소한 제 기준에서는 당연히 서버와 클라이언트 양쪽에서 중복해서 만들고 중복해서 검증해야 되는 것이라고 봅니다. 특히 서버와 클라이언트의 독립성 확보를 위해서요.
또 데이터를 화면에 표시해주기 위한한 템플릿이나 뷰레이어는 프로그래밍 사이드의 비즈니스 로직에 포함되지 않는다고 봅니다.
물론 자료를 표시해 주는 방법이 사업적으로나 기획적인 의미로의 비즈니스 키 포인트일 수는 있겠지만, 서버 엔지니어링에서는 데이터를 다루는 핵심 부분만이 비즈니스 로직에 해당되겠죠.
만약 클라이언트 단독으로 처리할수 없는 기능이 있다면 당연히 서버단에서 처리할 수 있게끔 새 기능을 추가하고 기능에 해당하는 인터페이스를 만들어야 겠지만, 이건 REST 개념이 포함하고 있는 이루어지는 기능의 확장성 부분을 다루는 것이지 서버와 클라이언트가 상호 코드 의존성을 지니게 되는건 아니죠.
상호 의존성이 생긴다는 것은 프론트엔드의 로직이 없으면 서버가 동작하지 못하는 상황을 말하는데, 그런 상황에 처한 부분은 응당 전부 서버상에서 구현 후 입력값과 결과값만 상호 교환하도록 설계되어야 합니다.
아무튼 위에서 장황하게 설명하긴 했지만, 서버와 클라이언트간에 로직분리가 완벽하게 될수 있다는 소리는 아니지만, REST를 준수하면 상호간에 분리가 되는 것이지 서버는 데이터 입출력만 하고 프론트 엔드가 비즈니스 로직을 다루고 이런식으로 분리가 되는 것이 아닙니다.
오히려 WAX 스타일에서 종종 쓰이는 게이트웨이 서버들이 그런것에 더 가깝겠죠.