Rest API

구성

• 자원(Resource) - URI
• 행위(Verb) - HTTP method
• 표현(Representations)

디자인 가이드

1. URI는 정보의 자원을 표현
2. 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE)로 표현→ URI는 자원을 표현하는데 중점을 두어야 한다. delete와 같은 행위에 대한 표현이 들어가면 안된다. (행위에 대한 정보는 HTTP Method로 표현)

//회원 삭제
Get /members/delete/1 (X)
DELETE /members/1 (O)

//회원 추가
POST /members/2

→ URI는 자원을 표현하는데 중점을 두어야 한다. delete와 같은 행위에 대한 표현이 들어가면 안된다. (행위에 대한 정보는 HTTP Method로 표현)

Collection과 Documnet

Collection과 Documnet는 자원을 표현한다.

Collection

• Collection은 단일 리소스인 Document들의 묶음
• DB에서의 테이블과 유사
• 복수형으로 표현

Documnet

• Documnet는 Collection내의 단일 리소스
• DB에서의 한 테이블의 레코드와 유사
• 단수형으로 표현

/sports/soccer/players/13
-> collection : sports, players
-> Documnet : soccer, 13

설계 시 주의점

• 자원은 동사보다 명사, 소문자 사용

get /members (o)
   /getMember (X)

• URI 맨 뒤에 / 포함 X
• _보다는 - 사용
• 파일 확장자는 URI에 포함시키지 않는다.
  • REST API에서는 메시지 바디에 보낸 내용의 포맷을 Accept Header에 보낸다.

Accept Header : 클라이언트가 서버에 요청 시 처리 가능한 응답 데이터를 Accept Header에 담아 보냄.

HTTP method

• 일반적인 사용
  • Create - post
  • Read - get
  • Update -put
  • Delete = delete

REST의 단점

• 제한적인 Method 방식
• 표준이 없어 협업 시 개발자들끼리 스펙을 정할 필요가 있다.

REST의 장점

1. 역할 분리가 명확하다.
   • 서버는 요청에 대한 결과를 데이터로 넘겨줌
   • 화면에 대한 처리는 클라이언트 쪽에서 담당
2. URI와 Method만으로 어떤 요청인지 쉽게 파악할 수 있다.
3. HTTP 프로토콜을 그대로 사용하기 때문에 별도의 인프라 구축이 필요하지 않다