- REST API를 기존의 MVC 패턴으로 만들어보고, SpringBoot Data REST를 이용하여 개발해보는 레퍼지토리입니다.
REST는 웹과 같은 하이퍼미디어 시스템에서 사용하는 통신네트워크 아키텍쳐이며, HTTP와 URI의 단순하고, 간결한 장점을 계승한 네트워크 아키텍쳐입니다.
- REST의 목적
- 구성요소 상호작용의 규모확장성
- 인터페이스의 범용성
- 구성요소의 독립적인 배포
- 중간적 구성요소를 이용한 응답 지연감속, 보안강화, 레거시 시스템 인캡슐레이션
- 이 제약조건의 기본원칙은 관심사의 명확한 분리입니다. 관심사의 명확한 분리가 선행되면 서버의 구성요소가 단순화되고, 확장성이 향상되어 여러 플랫폼을 지원할 수 있습니다.
- 서버에 클라이언트 상태정보를 저장하지 않는 것을 말합니다. 단순히 들어오는 요청만 처리하여 구현을 더 단순화합니다. 단, 클라이언트의 모든요청은 서버가 요청을 알아듣는 데 필요한 정보를 담고 있어야합니다.
- 클라이언트의 컨텍스트(세션, 쿠키 등)을 서버에 저장하지 않습니다. 이로써 서비스의 자유도가 높아지게됩니다.
- 클라이언트의 응답을 캐시할 수 있어야 합니다. 따라서 HTTP의 캐시기능도 적용할 수 있습니다.
- 서버는 중개서버나 로드 밸런싱, 공유캐시 등의 기능을 사용하여 확장성 있는 시스템을 구성할 수 있습니다.
- 클라이언트는 서버에서 자바 애플릿, 자바스크립트 실행코드를 전송받아 기능을 일시적으로 확장할 수 있습니다. 이 제약조건은 선택가능!
- URI로 지정된 리소스에 균일하고, 통일된 인터페이스를 제공합니다. 아키텍처를 단순하게 분리하여 독립적으로 만들 수 있습니다.
REST API는 다음과 같이 구성되어야 합니다.
- 자원: URI
- 행위: HTTP 메서드
- 표현: 리소스에 대한 표현 (HTTP Message Body)
// 웹상의 파일의 위치를 URL방식으로 표현
http://localhost:8080/api/book.pdf
// 웹상의 파일의 위치를 URI방식으로 표현
http://localhost:8080/api/book/1
- URI는 URL을 포함하는 개념으로 위와 같은 차이를 보입니다.
- URL은 리소스를 가져오는 방법에대한 위치, URI는 문자열을 식별 하기위한 표준
- URI는 명사를 사용해야 하며 동사를 피해야하고, HTTP 메서드로 동사를 대신하여야합니다.
- 하지만, 모든 API동작을 HTTP메서드만으로 대응하기 힘들기 때문에 URI에 불필요한 동사를 포함하는 것을 지양해야 한다는 것이지 완전히 배제시킨다는 것은 아닙니다.
- URI는 단수가 아닌 복수형을 사용해야한다.
- HTTP 메서드를 이용해서 행위를 설계합니다.
- POST, GET, PUT, DELETE 등을 이용합니다.