REST API란?

2022.01.17 : REST 원칙 내용 보충

 

개인적으로 REST API를 완벽하게 이해하고 사용하고 있다고 생각했는데, 최근에 나의 설명이 완벽한 답변이 아니라고 해서 정리해둔다. 

REST란 Roy T. Fielding라는 사람의 박사논문에서 첫 소개된 개념이다. 

논문에 내용이다 보니 사실 방대하고 말이 어렵다. 사람들이 다 같은 마음인지, 논문의 내용을 정확하게 해석해서 사용하는 곳은 많지 않고 각 회사마다 각자의 사정에 맞추어 조금씩 다르다고 한다. 

 

 

"브라우저가 서비스를 어떤 형식으로 요청 보내고, 응답 받는지를 REST 아키텍처 스타일로 설계, 구현된 것"

 

 

목차

• REST API?
• REST 6가지 원칙
• REST 활용 
• 장/단점

 

---

REST API란?

Representational State Transfer (REST)로 

월드 와이드 웹(World Wide Web a.k.a WWW)과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식으로 자원을 정의하고 자원에 대한 주소를 지정하는 방법 전반에 대한 패턴.

 

분산 하이퍼미디어니, 소프트웨어 아키텍처의 형식이라느니 말은 너무 어려워 모르겠고 간단하게 요약하면 다음과 같다.  

"API 설계의 중심에 자원(Resource)이 있고 HTTP Method 를 통해 자원을 처리하도록 설계하는 것이다."

 

자원이란? web 프로젝트에서 html,css,js,db 같은 파일, 데이터가 될 수 있겠고, 이를 HTTP method GET/POST/PUT/PATCH/DELETE 로 처리하도록 설계하는 것.

 

---

REST 6가지 원칙

• Uniform Interface : URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일   

- 부연 설명 : 내 프로젝트가 수정할 일이 있다면, 수정하는 url (/post) 하나로 통일, JSON이면 JSON, HTML이면 HTML 응답 값이 통일 되어 있으면 REST.

• Stateless : 무상태성 성격. 한번 통신하면 끝! history를 저장하지 않는다. (such as 로그인 상태를 저장 못하는 것)

- 부연 설명 : 이전의 HTTP 요청들이 현재의 요청에 영향을 주지 못한다는 의미, 로그인 상태를 유지하고 싶다면 요청할때 로그인 정보까지 같이 보내야함.

• Caching : HTTP가 가진 캐싱 기능이 적용 가능합니다. (실제로 조작해본적은 없음)

- 서버에서 값을 리턴 할때, 캐시가 가능한지 아닌지를 명시할 수 있는지 -> HTTP 헤더에 cache-control에 명시 할 수 있어야 REST.

• Client-Server :  클라이언트는 사용자 인증이나 컨텍스트(세션, 로그인 정보)등을 직접 관리하는 구조로 각각의 역할이 확실히 구분되기 때문에 클라이언트와 서버에서 개발해야 할 내용이 명확해지고 서로간 의존성이 줄어들게 됩니다.

- 내 프로젝트에 리소스를 관리하는 서버가 존재하고, 리소스를 소비하려는 다수의 클라이언트가 있다면 REST.

• Hierarchical system :  REST 서버는 다중 계층으로 구성될 수 있으며 보안, 로드 밸런싱, 암호화 계층을 추가해 구조상의 유연성을 둘 수 있고 PROXY, 게이트웨이 같은 네트워크 기반의 중간매체를 사용할 수 있게 합니다.

- 내 프로젝트에 클라이언트가 인증 서버(https), 캐싱 서버, 로드 밸런서를 거쳐서 어플리케이션 서버에 도달하면 REST, 단! 클라이언트는 계층의 존재를 알지 못함. 

• Self-descriptiveness : REST의 또 다른 큰 특징 중 하나는 REST API 메시지만 보고도 이를 쉽게 이해 할 수 있는 자체 표현 구조로 되어 있다는 것 입니다.

• 코드 온 디멘드: (선택 사항) 클라이언트가 서버에 code를 요청할 수 있고, 리턴한 code가 실행할 수 있는 것.

---

 

그래서 RESTful API가 무슨 말인가? 

 

프로젝트 API 작성시 다음의 규칙을 지키면 RESTful 하다고 볼 수 있다.  

 

1. 리소스는 url로 표현하는데 이름만 보고 어떤 자원으로 접근하는지 알수 있어야한다. 

2. 행위는 HTTP method를 사용해서 사용 목적을 분명히한다.

3. HTTP message에 hearder와 body를 분명히 나누어 사용한다.

4. form으로 요청하면 form으로 응답을, JSON은 JSON으로.

5. url은 명사형으로 작성하고 영어의 복수형을 기본으로 한다. 필요할 경우에만 단수형 사용.

6. url 주소 계층은 "/" 로 나누고 필요하면 "-"를 사용한다. 대문자와 "_" 는 사용을 지양한다.

... 등등

---

 

장점/단점

 

사용하면 어떤 자원에 어떤 기능을 하는 api인지 한눈에 파악하기 쉽다. 

"/helloWorldBlogDelete..."등등 대문자, 창의적인 url이 점점 많아진다고 생각했을때 

프로젝트는 커지고 어떤 url이 뭐가 뭔지 모르는 사태가 온다면? 끔찍하다.

 

 

---

 

Resource

 

https://blog.npcode.com/2017/03/02/%EB%B0%94%EC%81%9C-%EA%B0%9C%EB%B0%9C%EC%9E%90%EB%93%A4%EC%9D%84-%EC%9C%84%ED%95%9C-rest-%EB%85%BC%EB%AC%B8-%EC%9A%94%EC%95%BD/

바쁜 개발자들을 위한 REST 논문 요약

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

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

https://spoqa.github.io/2012/02/27/rest-introduction.html

REST 아키텍처를 훌륭하게 적용하기 위한 몇 가지 디자인 팁