REST API 를 들어가기 앞서 API에 대하여 간단하게 정리하려한다.
API는 Application Programing Interface의 약어로써 사전적인 의미로는 운영체제와 응용프로그램 사이의 통신에 사용되는 언어나 메시지 형식을 말하는데, 쉽게 설명하면 식당에서 주방은 운영체제, 손님은 응용프로그램, API는 메뉴판으로써 손님이 메뉴판을 통해 주방에 주문을 넣는과정에서 메뉴판의 역활을 한다고 생각하면 된다.
REST는 Representational State Transfer의 약어로써 네트워크에서 통신을 관리하기 위해 만들어진 소프트웨어 아키텍처이다.
REST API 는 크게 3가지로 구성되어있다.
1. 자원(RESOURCE) - URI
2. 행위(Verb) - HTTP METHOD
3. 표현(Representations)
REST API의 특징으로는 다음과 같다.
1. Uniform(균일한 인터페이스) - URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일이다.
2. Stateless(무상태성) - REST API는 작업을 위한 상태정보를 따로 저장하고 관리하지 않는다.
3. Cacheable(캐시가능) - REST API는 HTTP라는 웹 표준을 그대로 사용하기에 HTTP의 캐싱기능이 적용 가능하다.
4. Self-Descriptiveness(자체 표현 구조) - REST API는 메시지만 보고도 쉽게 이해 할 수 있는 자체 표현 구조로 되어있다.
5. Client-Server 구조 - REST API Server는 API를 제공하고, Client는 사용자 인증이나 로그인정보 와 같은 컨텍스트를 직접 고나리하기에 서로의 의존성이 줄어들고 개발해야 하는 영역의 기준이 명확해진다.
6. 계층화 - REST API 서버는 다중계층으로 구성될 수 있다.
REST API 설계시 URI와 Method 표현이 매우 중요하다.
URI는 정보의 자원을 표현해야하고, 그에 대한 행위는 HTTP Method로 표현하는것이 특징을 잘살리고 옳은 표현이라고 할 수 있다.
GET /member/delete/1
위와 같은 방식은 잘못 되었다고 볼 수 있다. delete에 관한 Method로 DELETE가 제공되는데 GET형식으로 삭제를 요청한것은 올바르지 못하다고 볼 수 있다. 따라서 수정하면 다음과 같아진다.
DELETE /member/1
이처럼 Method로 해당 REST API의 역활을 충분히 보여줄 수 있는데, resource를 조회할때는 GET, 생성할때는 POST, 수정할때는 PUT, 제거할때는 DELETE를 이용해주면 된다.
REST API에 대한 응답 상태는 HTTP 응답 상태 코드를 통해 알 수 있는데 가장 자주 발생하고 사용되는 친구들만 알아보겠다.
200 - client 요청을 정상적으로 수행함.
201 - client가 resource 생성을 요청 > 성공.
301 - 클라이언트가 요청한 리소스에 대한 URI가 변경되었을 경우
400 - client의 요청이 부적절 할 경우
401 - client가 인증되지 않은 경우
403 - client 혹은 user의 인증상태와 관계없이 응답하고 싶지 않은 resource를 client가 요청 했을 경우(단, 이 경우는 resource가 존재한다는걸 가르켜줘버리는 불상사가 발생할 수 있기에 되도록이면 404나 400을 추천)
404 - 해당 API 혹은 Page를 찾지 못하였을 경우 (Not Found)
405 - 클라이언트가 요청한 리소스에서 사용 불가능한 Method를 이용했을 경우
500 - 서버에 문제가 있을 경우
502 - 서버가 요청을 처리하는데 필요한 응답을 얻기 위해 게이트웨이로 작업하는 동안 잘못된 응답을 수신했을경우
504 - 서버의 요청에 대해 서버가 시간내에 처리하지 못한 경우