RESTful API?
API 시스템을 구현하기 위한 아키텍처 중에 가장 널리 사용되는 형식
REST(Representational State Transfer)??
- 웹상에서 사용되는 여러 리소스를 HTTP URI로 표현하고 그 리소스에 대한 행위를 HTTP
Method로 정의하는 방식
- 즉, HTTP URI로 정의된 리소스를 HTTP Method + Payload 행태로 구조적으로 깔끔하게 표현함.
REST 구성
- 자원(RESOURCE) - URI
해당 사이트의 특정 자원의 위치를 나타내는 유일한 주소
- 행위(Verb) - HTTP METHOD
HTTP request가 의도하는 action을 정의한 것
- 표현(Representations)
HTTP request에서 server로 보내는 데이터 (body)
RESTful API의 장점
RESTful API의 장점 중 가장 큰 특징 2가지인 Self-descriptiveness
, Stateless
Self-descriptiveness(자체 표현 구조)
- 여러 장점들 중 가장 명확한 장점은 self-descriptiveness이다.
- RESTful API는 그 자체만으로도 API의 목적이 쉽게 이해가 된다.
Stateless (무상태성)
- REST는 무상태성 성격을 갖아서 작업을 위한 상태정보를 따로 저장하고 관리하지 않습니다.
- 세션 정보나 쿠키정보를 별도로 저장하고 관리하지 않기 때문에 API 서버는 들어오는 요청만을 단순히 처리하면 됩니다. 때문에 서비스의 자유도가 높아지고 서버에서 불필요한 정보를 관리하지 않음으로써 구현이 단순해집니다.
RESTful API 설계 규칙
첫 번째, URI는 정보의 자원을 표현해야 한다.(리소스명은 동사보다는 명사를 사용)
URI는 자원을 표현하는데 중점을 두어야하므로. delete와 같은 행위에 대한 표현이 들어가서는 안됩니다.
GET /members/delete/1
두 번째, 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE)로 표현한다.
위의 잘못된 URI를 HTTP Method를 통해 수장하면 하기와 같습니다.
DELETE /members/1
세 번째, URI는 / 구분자를 사용하여 자원의 계층 관계를 나타내는데 사용하며 마지막 문자로 /
를 포함하지 않는다.
네 번째, 불가피하게 URI가 길어지는 경우 -
을 사용하여 가독성을 높이고 _
는 사용하지 않는다.
다섯 번째, URI 경로에는 대문자 사용을 피하도록 규정하고 있다.
여섯 번째, 파일의 경우 payload의 포맷을 나타내기 위한 파일 확장자를 URI에 포함시키지 않는다.
Reference:
https://meetup.toast.com/posts/92
생활코딩