2021-03-10 일지2

< Rest API 내용 정리 >
* REST 구성
  > 자원(Resource): 자원은 Data, Meta Data, HATEOAS로 나뉨
  > 행위(Verb): HTTP Method로 표현
  > 표현(Representations)
  
* REST 특징
1) Uniform Interface (유니폼 인터페이스)
- 구성 요소(클라이언트, 서버 등) 사이의 인터페이스는 균일(uniform)해야 함
  인터페이스를 일반화함으로써, 전체 시스템 아키텍처가 단순해지고,
  상호 작용의 가시성이 개선되며, 구현과 서비스가 분리되므로 독립적인 진화가 가능해짐
2) Stateless (무상태성)
- 클라이언트와 서버의 통신에는 상태가 없어야 함
  모든 요청은 필요한 모든 정보를 담고 있어야 함
  요청 하나만 봐도 바로 뭔지 알 수 있으므로 가시성이 개선되고,
  task 실패시 복원이 쉬우므로 신뢰성이 개선되며,
  상태를 저장할 필요가 없으므로 규모 확장성이 개선될 수 있음
3) Cacheable (캐시 가능)
- 모든 서버 응답은 캐시가 가능한지 그렇지 아닌지 알 수 있어야 함
  효율, 규모 확장성, 사용자 입장에서의 성능이 개선됨
4) Self-descriptiveness (자체 표현 구조)
- REST API 메시지만 보고도 이를 쉽게 이해할 수 있는 자체 표현 구조로 되어 있음
5) Client-Server 구조
- 사용자 인터페이스에 대한 관심을 데이터 저장에 대한 관심으로부터 분리함으로써
  클라이언트의 이식성과 서버의 규모확장성을 개선할 수 있음
6) Layered System(계층형 구조)
- 다중 계층으로 구성될 수 있으며 보안, 로드 밸런싱, 암호화 계층을 추가해
  구조상의 유연성을 둘 수 있고 
  PROXY, 게이트웨이 같은 네트워크 기반의 중간매체를 사용할 수 있음
  
* REST API 설계 가이드
1) URI는 정보의 자원을 표현해야 함
- resource는 동사보다는 명사를, 대문자보다는 소문자를 사용
- resource의 도큐먼트 이름으로는 단수 명사를 사용
- resource의 컬렉션 이름으로는 복수 명사를 사용
- resource의 스토어 이름으로는 복수 명사를 사용
2) 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE)로 표현
3) URI에 HTTP Method가 들어가면 안 됨
4) URI에 행위에 대한 동사 표현이 들어가면 안 됨
  (즉, CRUD 기능을 나타내는 것은 URI에 사용하지 않음)
5) 경로 부분 중 변하는 부분은 유일한 값으로 대체
6) 슬래시 구분자(/)는 계층 관계를 나타내는데 사용
7) URI 마지막 문자로 슬래시(/)를 포함하지 않음
8) URI에 포함되는 모든 글자는 리소스의 유일한 식별자로 사용되어야 함
   URI가 다르다는 것은 리소스가 다르다는 것이고,
   역으로 리소스가 다르면 URI도 달라져야 함
9) 하이픈(-)은 URI 가독성을 높이는데 사용할 수 있음
10) 밑줄(_)은 URI에 사용하지 않음
11) URI 경로에는 소문자가 적합
12) 파일 확장자는 URI에 포함하지 않음 / Accept header를 사용하도록 함
13) 리소스 간에 연관 관계가 있는 경우 표현 방법
   : /리소스명/리소스 ID/관계가 있는 다른 리소스명
14) 자원을 표현하는 컬렉션(Collection)과 도큐먼트(Document)
- 컬렉션은 객체의 집합, 도큐먼트는 객체라고 생각하면 됨
- 컬렉션과 도큐먼트 모두 리소스로 표현할 수 있으며 URI로 표현할 수 있음

* HATEOAS: DATA와 함께 관련된 URL 정보를 제공하는 것