RESTful API란?

안드로이드/iOS 개발을 하면서 API 통신을 할 때 보는 것이 RESTful API였는데요, 평소 RESTful API가 무엇인지 두루뭉실하게만 알고 있어서 누군가 물어본다면 얼버무리게 되어 한 번쯤은 날 잡고 정리를 해보고 싶었습니다. RESTful API가 뭔지 설명하기까지 우리가 알아야 할 건 REST가 무엇인지, REST가 가진 원칙이 무엇인지, 그래서 RESTful API가 무엇인지, 어떤 규칙이 있는지, 응답상태코드는 어떤게 있는지 등을 알아야 할 것 같습니다.

 

그럼 시작해볼까요?

 

 

 

REST란?

REST는 Representational State Transfer의 줄임말입니다. 그냥 직역하면 대표적인 상태 전송이 되네요? 이게 무슨 말일까요? REST는 자원을 이름(자원의 표현)으로 구분하여 해당 자원의 상태(정보)를 주고 받는 것을 의미합니다. 즉, URI를 통해 어떤 자원인지 명시하고, HTTP Method (GET, POST, PUT, PATCH, DELETE) 에 따라 해당 자원을 처리하여 자원의 상태(Representation)를 응답하도록 설계된 아키텍쳐입니다. 하지만 참고로 REST는 이렇게 구현하면 좋다는 설계 가이드일 뿐이지 정확한 표준은 없습니다!!

 

REST는 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하고 있습니다. 그래서 HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능(Uniform Interface = 인터페이스 일관성)합니다.

 

그리고 HTTP가 무상태성 프로토콜 (Stateless Protocol) 이기 때문에 REST 역시 무상태성(Stateless)을 갖습니다. 엥?? 아까는 상태를 주고 받는다면서! 라고 생각할 수 있지만, 세션 정보나 쿠키를 별도로 저장하지 않고 관리하지 않기 때문에 API서버는 들어오는 요청만 단순히 수행합니다.  즉, 상태는 입력되는 정보이고 입력되는 상태에 따라 처리한다는 것이죠. 이런 특성 덕분에 서비스의 자유도가 높아져서 서버에서 불필요한 정보를 관리하지 않게 되고 구현이 단순해집니다.

 

REST는 웹 표준 HTTP 프로토콜을 그대로 사용하기 때문에 웹에서 사용하는 기존의 인프라를 그대로 활용할 수 있는데, HTTP가 가진 캐시 처리 기능(Cacheable)을 활용하여 대량의 요청을 효율적으로 처리할 수 있게 됩니다.

 

또한, REST는 클라이언트-서버 구조를 갖습니다. 클라이언트는 사용자 인증이나 컨텍스트(세션, 로그인정보) 등을 직접 관리하고 책임집니다. REST 서버는 API를 제공하고 비즈니스 로직 처리 및 저장을 책임집니다. 이렇게 각각의 역할이 확실히 구분되기 때문에 서로 간의 의존성이 줄어듭니다. 클라이언트는 REST API 서버만 호출하지만, 실제로 서버는 다양한 계층(Layered System)으로 구성될 수 있습니다. 예를 들어, 보안이나 암호화 계층을 추가해 구조 상의 유연성을 둘 수도 있고, 프록시나 게이트웨이 같은 네트워크 기반의 중간 매체를 사용할 수 있게 합니다.

 

 

 

그래서 RESTful API가 뭔데?

API는 Application Programming Interface의 줄임말로 프로그램과 또 다른 프로그램을 연결해주는 일종의 다리라고 볼 수 있습니다. 따라서 REST API는 REST라는 아키텍쳐를 기반으로 구현되는 API를 말하게 됩니다. 즉, HTTP 요청을 보낼 때 어떤 URI에 어떤 메서드를 사용할지 개발자들 사이에 널리 지켜지는 약속이라고 할 수 있습니다. RESTful API는 따로 정의된 것이 아니라 일반적으로 REST라는 아키텍처를 구현하는 웹 서비스를 나타내기 위해 사용되는 용어입니다. 따라서 REST API를 제공하는 웹 서비스를 RESTful하다고 할 수 있습니다.

 

 

 

REST API 설계 규칙

REST API에서 URI는 정보의 자원을 표현하기 때문에 동사보다는 명사를, 대문자보다는 소문자를 사용합니다. 그리고 자료에 따라 단수 명사, 복수 명사를 구분합니다. 이러한 자원에 대한 행위는 HTTP Method (GET, PUT, POST, DELETE 등)로 표현합니다. URI에는 HTTP Method가 들어가서는 안되고, URI에 행위에 대한 동사 표현(get, put, post, delete 등)이 들어가면 안됩니다.

 

REST API에서 슬래시 구분자( / )는 계층 관계를 나타내는데 사용됩니다. 따라서 URI 마지막 문자로 슬래시( / )를 포함하지 않도록 합니다. 밑줄(_)은 URL 링크 밑줄이랑 겹쳐지기 때문에 URI에 사용하지 않고, 하이픈(-)으로 URI의 가독성을 높입니다. 또한, URI에 파일확장자가 포함되지 않도록 주의해야 합니다.

 

REST API의 응답 상태 코드로는 아래와 같이 볼 수 있습니다.

 

▪️1xx : 정보 응답

▪️2xx : 성공 응답

200은 단순히 작업이 성공했다는 뜻, 201은 회원가입처럼 작업이 성공하고 새로운 리소스를 생성했다는 뜻, 204는 보통 삭제 응답으로 쓰이고 작업이 성공했고 더이상 이 리소스를 찾을 수 없을 거다 라는 뜻입니다.

▪️3xx : 리다이렉션 메시지

클라이언트가 요청한 리소스가 옮겨졌거나 리소스가 삭제되었거나해서 정상적인 방법으로는 더 이상 해당 리소스에 접근할 수 없고 다른 URL을 통해서 그 리소스에 접근해야하는 경우 서버는 “여기로 가면 너가 찾는 리소스가 있어!”라는 정보를 알려줄 수 있는데, 이때 사용되는 상태 코드들이 바로 300번대 코드들입니다.

▪️4xx : 클라이언트 에러 응답

400은 클라이언트가 요청을 잘못 날렸다는 뜻, 401은 인증이 필요하다는 뜻, 403은 이 리소스를 요청하는건 금지되었다는 뜻, 404는 요청한 리소스가 존재하지 않는다는 뜻, 405는 현재 리소스에 맞지 않는 메서드를 사용했다는 뜻, 429는 클라이언트가 서버에 너무 많은 요청을 보냈다는 뜻입니다.

▪️5xx : 서버 에러 응답

 

 

 

 

 

 

 

 

 

Reference

기술면접 준비하기-2

 

NAVER 기술 면접 리뷰