REST API

 

🧑‍💻

RESTful, RESTAPI, 웹 개발을 하는 사람이라면 RESTful API를 못 들어볼 수가 없다. 근데 REST API는 구현할 줄 알아도, 정작 이것이 무엇인지에 대해서는 개념이 잡혀있지 않았다.

뭔지도 모르는 것을 구현할 줄 안다는 것은 사용법도 모르는 도구를 사용한다는 것이라는 생각을 했다.

이번 기회로 REST API에 대해 자세히 공부하고 정리해보려 한다.

 

 

 

📚 API는 무엇일까?

API(Applicaion Programming Interface)는

소프트웨어 애플리케이션 또는 시스템 간에 데이터를 주고받거나 기능을 공유할 수 있도록 하는 인터페이스이다.

쉽게 말해, API는 서버와 클라이언트 혹은 다른 서비스와의 통신을(데이터를 주고받기) 위해 사용하는 것이다.

 

📚 RESTful, REST는 무엇일까?

REST(Representational State Transfer)는 API의 한 종류이다. 다시 말하자면, API는 서버와 클라이언트가 데이터를 주고받기 위해 사용하는 것이고, REST는 그러한 API를 구현하는 방법 혹은 아키텍처 스타일 중 하나인 셈이다.

🧑‍💻

도쿄식 오코노미야키냐 오사카식 오코노미야키냐 같은 느낌

 

📚 그럼 왜 REST API 구현을 강조할까?

단순하게 접근해 보면 REST가 가진 여러 장점 때문일 것이다. 기본적으로 REST는 인터넷에서 데이터를 교환할 때 사용되는 웹 표준과 프로토콜을 기반으로 한다는 장점이 있는데, 이밖에 REST API의 대표적인 장점에 대해 이야기해 보겠다.

1. 단순성 : REST는 HTTP 프로토콜을 사용하기 때문에, 개발자들이 익숙한 웹 표준과 아키텍처로 애플리케이션을 개발할 수 있다.
   
   
2. 무상태성(Stateless) : REST는 상태를 가지지 않는다. 즉, 무상태(stateless)성을 띄고 있다. 다시 말해, 서버에서는 클라이언트의 상태를 저장하고 있지 않다는 것이다.
   🧑‍💻  로그인을 한 유저가 인가된 유저만이 접근할 수 있는 요청을 서버에 보냈다고 할 때, 서버에서는 클라이언트의 상태를 저장하지 않기(stateless)에 인가된 유저인지를 판별할 수 있는 근거가 없다. 그래서 매 요청에 유저 정보를 같이 보내야 한다.
   
   
3. 캐싱(Caching) : HTTP 프로토콜을 사용하고 있어 HTTP 프로토콜의 캐시 기능을 활용해 요청에 대한 리소스를 저장할 수 있다.
   🧑‍💻 캐싱은 요청에 대한 리소스를 저장하는 기술이기에 요청에 대한 같은 응답에 대해서는 서버에 직접적으로 요청을 하지 않고 캐싱된 곳에서 리소스를 가져올 수 있다. 이는 요청에 대한 응답 시간을 단축시킬 수 있다는 이점이 있다.

 

📚 REST와 RESTful의 차이

둘의 차이는 없다고 볼 수 있지만, 엄밀히 따진다면 REST 원칙을 엄격하게 준수하는 API를 지칭할 때 RESTful을 사용한다고 한다.

 

 

📚 내가 작성한 코드가 REST API가 맞나요..?

REST API에 대해 스터디하면서 REST한 것의 장점이 무엇인지 왜 REST API를 구현하는지 알게 되었다. 또한, 이미 많은(어쩌면 모든 프레임워크..?) 프레임워크들에서 REST API를 작성하도록 설계가 되어있구나라는 생각을 하게 됐다.

 

여태 Spring Boot와 DRF를 활용해 API를 작성하면서 프레임워크에서 제공하는 도구나 라이브러리들을 활용해서 API를 구현했을 뿐인데 그것들이 REST API라고 부르는 것들이었다.

 

물론 모든 프레임워크를 다뤄본 것도 아니고 다뤄본 프레임워크 중에서도 위의 말이 틀린 것일 수도 있지만, 여태 REST 원칙을 따르는 API를 작성해야지라는 마음으로 API를 만들어 본 적은 없었다는 것이다.

 

찾아보니 프레임워크들에서 REST API를 작성할 수 있도록 설계가 되어있고, REST 원칙을 잘 준수해서 API를 만드는지에 대해서는 코드를 작성하는 사람의 몫이라고 한다.

 

 

📚 REST 원칙을 준수하며 API를 설계하는 법

많은 곳에서 REST API를 강조하고 있지만 실질적으로 REST 원칙을 잘 준수하는 것은 개발자의 몫이기에 REST의 원칙이 무엇인지에 대해 이야기해보고자 한다.

1. 자원을 중심으로 URL을 구성
   • 게시판에 대한 api를 작성하는 것인데 /users로 url을 구성하면 REST 원칙에 어긋난다.
2. 요청에 걸맞은 적절한 HTTP 상태 코드 사용
   • 성공적인 GET 요청에는 200 OK, 새로운 리소스 생성에는 201 Created, 잘못된 요청에는 400 Bad Request 등 요청에 대해 적절한 상태 코드를 응답해줘야 하는 것이 REST 원칙이다.
3. 무상태성(Stateless)
   • 서버가 클라이언트의 상태 정보를 저장하지 않는 것이 REST 원칙이다. 클라이언트의 정보를 서버가 저장할 수도 있는데, 이러면 무상태성에 위배가 되는 것이기에 클라이언트 개발자와 서버 개발자가 사전에 약속을 하고 클라이언트의 상태를 서버에서는 저장하지 않고, 반대로 클라이언트는 필요한 모든 정보를 요청에 포함시켜 서버에게 보내줘야 한다.