REST (RESTful)

• REpresentational State Transfer 의 약자
• 자원을 URI로 표현하고 해당 자원의 상태를 주고 받는 것
• 분산 하이퍼미디어 시스템(예: 웹)을 위한 아키텍쳐 스타일
• 네트워크 상의 Client와 Server 사이의 통신 방식 중 하나

REST 구성

자원 ( Resource ) - URI

• 모든 자원에 고유한 ID가 존재하고, 이 자원은 Server에 존재한다.
• Client는 URI를 이용해서 자원을 지정하고 해당 자원의 상태(정보)에 대한 조작을 Server에 요청한다.
• URI의 형식은 https://{serviceRoot}/{collection}{id} 이어야한다.

❓ URI와 URL의 차이점

• URL : Uniform Resource Locator로 인터넷 상 자원의 위치
• URI : Uniform Resource Identifier로 인터넷 상의 자원을 식별하기 위한 문자열의 구성
  포함관계
  URI ( 동물 ) / URL ( 강아지 )

행위 ( Verb ) - HTTP METHOD

• GET / POST / PUT / PATCH / DELETE

표현 ( Representation )

• 그 자원을 표현하기 위한 이름
• 데이터베이스의 사용자 정보가 자원일 때, 'user'를 자원의 표현으로 지정

이러한 자원의 표현으로 클라이언트가 원하는 상태 즉 정보를 전달함
여기서 상태는 데이터가 요청되어지는 시점에서의 자원의 상태 ( 정보 ) 이며,
JSON 혹은 XML을 통해 데이터를 주고 받는 것이 일반적임

REST API

• REST한 방식으로 데이터를 상호교환하게 설계된 API (Application Programming Interface )

REST API 디자인 가이드

1. URI는 정보의 자원을 표현할 것
2. 자원의 행위는 HTTP METHOD 로 표현할 것

REST API 중심 규칙

1 ) URI는 정보의 자원을 표현 ( 리소스명은 동사보다는 명사를 사용 )

# Bad
GET /users/delete/1

• URL는 자원을 표현하는데 중점을 두어야함 ( delete 와 같은 행위에 대한 표현이 들어가면 안됨 )

2 ) 자원에 대한 행위는 HTTP METHOD 로 표현

# Good 
DELETE /users/1

CRUD	HTTP METHOD	Route
resource들의 목록을 표시	GET	/resource
resource 하나의 내용을 표시	GET	/resource/:id
resource를 생성	POST	/resource
resource를 수정	PUT	/resource/:id
resource를 삭제	DELETE	/resource/:id

REST는 왜 쓰나요?

• 멀티 플랫폼에 대한 지원이 용이함
• Stateless한 상태를 유지할 수 있다.
  - 다양한 브라우저와 모바일에서 통신할 수 있음
  - 클라이언트는 서버에 종속적이지 않아도 됨
  - Client는 서버 환경이 분산되었든 아니든, Server를 신경쓸 필요없이 API 호출만 하면 원하는 결과를 받을 수 있음
  

마무리

---

REST API가 그래서 뭐야 ?

• HTTP를 잘 사용하기 위해서 URI로 어떤 자원에 접근할 것인지,
  METHOD로 어떤 행위를 할 것인지 표현하여 설계된 API

---

REST API를 공부하면 할수록 RESTful하게 개발한다는 것은 정말 어렵다고 생각합니다.
지켜야할 룰이 굉장히 많고 그것을 다 지키자니 개발 생산성이 떨어지는 딜레마에 빠지게 되는 것 같습니다.
그래서 개발자들마다 REST API 작성스타일이 다 다른가? 라는 생각도 들었습니다.
다음 시간에는 HTTP API를 공부해서 REST API랑 어떤 점이 다른지 알아보겠습니다.

---

출처 및 참고

• REST API 제대로 알고 사용하기
• Web - REST, REST API, RESTful