REST (Representational State Transfer, 자원의 상태 전달)
네트워크 아키텍처 원리
Client , Server
클라이언트와 서버가 서로 독립적으로 분리되어져 있어야 한다.
Stateless
요청에 대해서 클라이언트의 상태가 서버에 저장을 하지 않는다.
캐시
클라이언트는 서버의 응답을 캐시 할 수 있어야 한다.
클라이언트가 캐시를 통해서 응답을 재사용할 수 있어야 하며, 이를 통해서 서버의 부하를 낮춘다.
계층화 ( Layered System )
서버와 클라이언트 사이에, 방화벽, 게이트웨이, Proxy 등 다계층 형태를 구성할 수 있어야 하며, 확장 할 수 있어야 한다.
인터페이스 일관성
아키텍처를 단순화시키고 작은 단위로 분리하여서, 클라이언트, 서버가 독립적으로 개선될 수 있어야 한다.
Code On Demand ( optional )
자바 애플릿, 자바스크립트 플래시 등 특정기능을 서버가 클라이언트에 코드를 전달하여 실행 할 수 있어야 한다.
인터페이스의 일관성
인터페이스 일관성이 잘 지켜졌는지에 따라 REST를 잘 사용했는지 판단을 할 수 있다.
- 자원 식별
- 메시지를 통한 리소스 조작
- 자기 서술적 메시지
- 애플리케이션 상태에 대한 엔진으로서 하이퍼미디어
자원식별
웹 기반의 REST에서는 리소스 접근을 URI를 사용합니다.
https://foo.co.kr/user/100
Resource : user
식별자 : 100메시지를 통한 리소스 조작
Web에서는 다양한 방식으로 데이터를 전송 할 수 있습니다.
그중에는 HTML, XML, JSON, TEXT 등등 다양한 방법이 있습니다.
이 중에서 리소스의 타입을 알려주기 위해서 header 부분에 content-type 를 통해서 어떠한 타입인지를 지정할 수 있습니다.
자기서술적 메시지
요청 하는 데이터가 어떻게처리 되어져야 하는지 충분한 데이터를 포함 할 수 있어야 합니다.
HTTP 기반의 REST에서는 HTTP Method 와 Header의 정보로 이를 표현할 수 있습니다.
애플리케이션 상태에 대한 엔진으로서 하이퍼미디어
REST API를 개발할때에도 단순히 Client 요청에 대한 데이터만 내리는것이 아닌 관련된 리소스에 대한 Link 정보까지 같이 포함 되어야 한다.
이러한 조건들을 잘 갖춘 경우 REST Ful 하다고 말하고 이를 REST API 라고 부릅니다.
REST Ful 이란
RESTFUL이란 REST의 원리를 따르는 시스템을 의미합니다.
하지만 REST를 사용했다 하여 모두가 RESTful 한 것은 아닙니다. REST API의 설계 규칙을 올바르게 지킨 시스템을 RESTful하다 말할 수 있다.
모든 CRUD 기능을 POST로 처리 하는 API 혹은 URI 규칙을 올바르게 지키지 않은 API는 REST API의 설계 규칙을 올바르게 지키지 못한 시스템은 REST API를 사용하였지만 RESTful 하지 못한 시스템이라고 할 수 있습니다.
RESTful API 이점
확장성
REST API를 구현하는 시스템은 REST가 클라이언트-서버 상호 작용을 최적화하기 때문에 효율적으로 크기 조정할 수 있습니다.
무상태는 서버가 과거 클라이언트 요청 정보를 유지할 필요가 없기 때문에 서버 로드를 제거합니다. 잘 관리된 캐싱은 일부 클라이언트-서버 상호 작용을 부분적으로 또는 완전히 제거합니다.
이러한 모든 기능은 성능을 저하시키는 통신 병목 현상을 일으키지 않으면서 확장성을 지원합니다.
유연성
RESTful 웹 서비스는 완전한 클라이언트-서버 분리를 지원합니다.
각 부분이 독립적으로 발전할 수 있도록 다양한 서버 구성 요소를 단순화하고 분리합니다. 서버 애플리케이션의 플랫폼 또는 기술 변경은 클라이언트 애플리케이션에 영향을 주지 않습니다.
애플리케이션 함수를 계층화하는 기능은 유연성을 더욱 향상시킵니다. 예를 들어, 개발자는 애플리케이션 로직을 다시 작성하지 않고도 데이터베이스 계층을 변경할 수 있습니다.
독립성
REST API는 사용되는 기술과 독립적입니다.
API 설계에 영향을 주지 않고 다양한 프로그래밍 언어로 클라이언트 및 서버 애플리케이션을 모두 작성할 수 있습니다. 또한 통신에 영향을 주지 않고 양쪽의 기본 기술을 변경할 수 있습니다.
URI 설계
1. URI (Uniform Resource Identifier)
인터넷에서 특정 자원을 나타내는 주소값. 해당 값은 유일 합니다.
ex : https://www.foo.co.kr/resource/sample/1
response : sample1.pdf, sample2.pdf, sample.doc
2. URL (Uniform Resource Locator)
인터넷 상에서의 자원, 특정 파일이 어디에 위치하는지 식별 하는 주소
ex : https://www.foo.co.kr/sample1.pdf
URL는 URI의 하위 개념입니다.
URI 설계원칙 (RFC-3986)
-
슬래시 구분자 ( / )는 계층 관계를 나타내는 데 사용한다.
https://foo.co.kr/vehicles/suv/q6 -
URI 마지막 문자로 ( / ) 는 포함하지 않는다.
https://foo.co.kr/vehicles/suv/q6/ -
하이픈(-)은 URI가독성을 높이는데 사용한
https://foo.co.kr/vehicles/suv/q-series/6 -
밑줄(_)은 사용하지 않는다.
https://foo.co.kr/vehicles/suv/q_series/6 -
URI 경로에는 소문자가 적합하다.
-
파일 확장자는 URI에 포함하지 않는다.
https://foo.co.kr/vehicles/suv/q6.jsp -
프로그래밍 언어에 의존적인 확장자를 사용하지 않는다.
https://foo.co.kr/vehicles/suv/q6.do -
구현에 의존적인 경로를 사용하지 않는다.
https://foo.co.kr/servlet/vehicles/suv/q6 -
세션 ID를 포함하지 않는다.
https://foo.co.kr/vehicles/suv/q6?session-id=abcdef -
프로그래밍 언어의 Method명을 이용하지 않는다.
https://foo.co.kr/vehicles/suv/q6?action=intro -
명사에 단수형 보다는 복수형을 사용해야 한다. 컬렉션에 대한 표현은 복수로 사용https://foo.co.kr/vehicles/suv/q6
-
컨트롤러 이름으로는 동사나 동사구를 사용한다.
https://foo.co.kr/vehicles/suv/q6/re-order -
경로 부분 중 변하는 부분은 유일한 값으로 대체 한다.
https://foo.co.kr/vehicles/suv/q7/{car-id}/users/{user-id}/release
https://foo.co.kr/vehicles/suv/q7/117/users/steve/release -
CRUD 기능을 나타내는것은 URI에 사용하지 않는다.
- GET : https://foo.co.kr/vehicles/q7/delete/{car-id} ( X )
- DELETE : https://foo.co.kr/vehicles/q7/{car-id} ( O )
-
URI Query Parameter 디자인
- URI 쿼리 부분으로 컬렉션 결과에 대해서 필터링 할 수 있다.
- URI 쿼리는 컬렉션의 결과를 페이지로 구분하여 나타내는데 사용한다.
-
API에 있어서 서브 도메인은 일관성 있게 사용해야 한다.
https://foo.co.krhttps://api.foo.co.kr -
클라이언트 개발자 포탈 서브 도메인은 일관성 있게 만든다.
https://dev-api.foo.co.kr/vehicles/suv/q6
https://developer-api.foo.co.kr/vehicles/suv/q6
OSI 7 Layer
OSI 7 Layer 데이터 흐름
일반적인 흐름
일반적인 인터넷(HTTP) 통신 예제
클라이언트 송신 기준 
서버 기준 
OSI 7 Layer 데이터 흐름 출처 : https://velog.io/@jakeseo_me/OSI-7%EA%B3%84%EC%B8%B5-%EC%8B%9C%EB%A6%AC%EC%A6%88-6-OSI-7%EA%B3%84%EC%B8%B5-%EC%A0%84%EC%B2%B4%EC%A0%81%EC%9D%B8-%ED%9D%90%EB%A6%84-%EC%A0%95%EB%A6%AC