REST API(Representational State Transfer API)

- REST API(Representational State Transfer API)

HTTP 프로토콜을 통해 API를 설계하기 위한 아키텍처 스타일

- 구성

자원(Resource-URI), 행위(Verb-HTTP Method), 표현(Representations)

- 특징

1. Uniform(유니폼 인터페이스): URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일
2. Stateless(무상태성): 작업을 위한 상태정보를 따로 저장하고 관리하지 않음(세션 정보나 쿠키 정보)  >> 서비스의 자유도 높음, 구현 단순
3. Cacheable(캐시 가능): REST는 HTTP 웹 표준을 그대로 사용하기 때문에 HTTP가 가진 캐싱 기능 적용 가능
4. Self-descriptiveness(자체 표현 구조): REST API 메시지만 보고도 쉽게 이해 할 수 있는 자체 표현 구조로 되어있음
5. Client-Server 구조: REST 서버는 API 제공, 클라이언트는 사용자 인증 or 컨텍스트(세션, 로그인 정보)를 직접 관리하는 구조로 각각의 역할이 확실히 구분

 클라이언트와 서버에서 개발해야 할 내용이 명확해지고 서로간의 의존성 줄어듬
6. 계층형 구조: 다중 계층 구성 가능

 보안, 로드 밸런싱, 암호화 계층 추가 가능

 Proxy, 게이트웨이 같은 네트워크 기반 중간 매체를 사용할 수 있음

- REST API 설계 시 가이드(중요)

1. URI는 정보의 자원을 표현해야 한다(리소스는 동사보단 명사 사용).
2. 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE)로 표현한다.

ex)
 GET /members/delete/1 는 1번 규칙 위배, 2번 규칙을 사용하여
 DELETE /members/1 로 수정해야함
회원 정보를 가져올때는 GET, 회원 정보를 추가할땐 POST

- HTTP Method의 역할

4가지 메소드로 CRUD(Create, Read, Update, Delete)
 POST: POST로 URI를 요청하면 리소스를 생성
 GET: 리소스를 조회 / 해당 도큐먼트에 대한 자세한 정보 가져옴
 PUT: 리소스를 수정
 DELETE: 리소스를 삭제

- 주의할 점

1. 슬래시(/) 는 계층 관계를 나타내는데 사용
2. URI 마지막 문자에 슬래시 사용 x
3. 하이픈(-)은 URI 가독성 높이는데 사용(긴 URI 경로에 사용)
4. 밑줄(_)은 사용 x / 밑줄 대신 하이픈 사용
5. 대문자 사용은 피해야함
6. 파일 확장자(~~.jpg)는 URI에 포함 x

- 리소스 간의 관계 표현

REST 리소스 간 연관 관계가 있을 경우
/리소스명/리소스id/관계가 있는 다른 리소스명
ex) GET : /users/{userid}/devices (일반적으로 소유 ‘has’의 관계를 표현할 때)

- Collection과 Document

자원을 표현 / 둘 다 리소스이며 URI에 포함
Document: 문서 or 객체 느낌
Collection: 문서 or 객체들의 집합
ex: http:// restapi.example.com/sports/soccer/players/13에서 sports, players는 컬렉션, soccer, 13은 도큐먼트
컬렉션은 복수, 도큐먼트는 단수로 표현

- 주요 HTTP 응답 상태 코드

200: 클라이언트의 요청 정상 수행
201: 리소스 성공적으로 생성됨(POST)
400: 클라이언트 요청이 부적절
500: 서버에 문제가 있음

 

 

 

- 공부하게 된 계기

 프론트엔드와 백엔드가 통신하는 프로젝트들을 만들어보는 도중 REST API가 있다는 것을 알게 되었고, 만들던 프로젝트들과 앞으로 만들 프로젝트들에 적용시키기 위하여 공부

 

 

 

 

 

 

 

참고:

https://meetup.nhncloud.com/posts/92

REST API 제대로 알고 사용하기 : NHN Cloud Meetup