REST, REST API, RESTful API 본격 알아보기
들어가며
안녕하세요, 이젠 누군지 다들 아실법한 풀스택 개발자 비니입니다.
마이크로서비스 아키텍처가 떠오르고, 클라우드 시스템이 발전하면서
REST 구현 능력에 대한 언급이 자주 등장하고 있는 것 같아요.
이 REST API, 이게 뭔지 스스로 정리할 겸 기록을 남겨보고자 합니다.
REST란?
Representational State Transfer.
REST는 자원을 URI로 식별하고, HTTP Method를 활용해 자원의 상태를 전송하는 스타일입니다.
더 확실하게 말하면,
자원을 URI를 통해 명시하고, HTTP Method를 통해 적용하는 것을 의미합니다.
- HTTP Method?
1. POST, GET, DELETE 등, 어디선가 들어 본 메소드들이 HTTP Method로 불립니다.
2. REST에서는 "CRUD" 를 구현할 때 사용됩니다.
- CRUD?
1. (C)reate : 생성을 담당하며, "POST" Method가 담당합니다.
2. (R)ead : 읽기를 담당하며, "GET"
3. (U)pdate : 수정을 담당하며, "PUT", "PATCH"
4. (D)elete : 삭제를 담당하며, "DELETE"
Q. 어? 수정은 왜 PUT과 PATCH 두개로 표현해요?
수정 범위에 따라 구분하고 있습니다.
"PATCH" Method는 객체의 "일부"를 수정할 때,
"PUT" Method는 객체 "전체"를 수정할 때 사용됩니다.
우리가 게임을 하다 보면, 서버 "패치"한다고들 하죠,
일부 버그들을 수정할 때. 그렇게 이해하면 쉽습니다.
REST의 장단점?
장점
- HTTP 프로토콜을 그대로 사용합니다. 그 말은, "REST"를 구현하기 위해 새로운 인프라를 만들 필요가 없어요.
- 서버, 그리고 클라이언트간 역할을 명확히 분리할 수 있습니다.
- "HTTP" 프로토콜을 사용할 수 있는 모든 플랫폼에서 사용할 수 있습니다.
- 보다 명확하고 직관적으로 Method를 구성하기 때문에, 협업과 프로세스 의도를 이해하기가 쉽습니다.
단점
- Over-fetching/Under-fetching 문제가 있습니다.
클라이언트가 필요 이상으로 데이터를 받거나, 필요한 데이터를 받지 못하는 경우가 발생할 수 있어요.
이를 해결하기 위해, GraphQL이란 기술이 탄생했답니다. 이건 나중에 알아보죠. - HTTP에 의존적입니다.
장점이었던 HTTP 프로토콜에 대한 의존성은, 역으로 다른 프로토콜을 활용하는 데 제약이 있을 수 있습니다.
REST API란.
Representational State Transfer Application Programming Interface.
앞서 설명한 REST를 기반으로 작성 된 API를 말합니다.
REST API의 규칙
1. API의 URI는 명사를 사용하여야 한다.
- 잘못된 예 : http://xxx.com/read-now
- 옳은 예 : http://xxx.com/book
2. 대문자가 아닌, 소문자를 사용하여야 한다.
- 잘못된 예 : http://xxx.com/READ
- 옳은 예 : http://xxx.com/read
3. 언더바(_) 가 아닌, 하이픈(-)을 사용한다.
- 잘못된 예 : http://xxx.com/read_book
- 옳은 예 : http://xxx.com/read-book
4. Method를 URI에 포함하지 않는다
- 잘못된 예 : http://xxx.com/get-book/1
- 옳은 예 : http://xxx.com/book/1
RESTful API란
REST를 기반으로 작성 된 API를 말합니다.
네, REST API와 같은 설명이지만 다르게 말하고 있어요.
- "REST"를 기반으로 작성한 모든 API는 "REST API"라 말할 수 있다.
- 하지만, "REST"를 사용하지만 올바르지 않게 사용한 경우는 "RESTful API"라 말할 수 없다.
- 즉, 완벽한 REST API는 RESTful API라고도 말할 수 있다.
예시
1. 기존에 있던 데이터를 수정하는 API
-> http://xxx.com/book/1 (POST)
-> http://xxx.com/book/1 (PUT)
이 경우, "수정"은 "POST"가 아닌, "PUT" 또는 "PATCH"로 진행하여야 합니다.
"POST"를 사용한 것은 "REST API"이지만,
"PUT"을 사용한 것은 "RESTful API"이자 "REST API"인 것이죠.
2. 기존 책 정보를 읽어오는 API
-> http://xxx.com/get_BOOK/1 (GET)
-> http://xxx.com/book/1 (GET)
이 경우, Method는 맞지만 REST API의 규칙을 어기고 있습니다. 이 경우는 "REST API"로 불립니다.
그 아래 URL의 경우엔 "RESTful API"이자 "REST API"인 것이죠.
쉽게 말하면...
REST의 규칙을 따르되, 보다 엄격한 규칙을 반영하고 있는 API를 "RESTful API"라 합니다.
그 외 "REST"의 규칙을 따르는 모든 API는 REST API라 부르면 됩니다.
마치며
많은 기업에서 "RESTful API 구현 가능" 또는 "REST 구현 가능"을 명시하고 있습니다.
우리 모두 구현을 할 수는 있으니, 이론에 대해서 빠삭하게 알고 있다면
기술면접에서 정말 좋은 효과가 있지 않을까요?
이 과정에서 얻은 교훈은 간단합니다.
"REST API" 구현에 있어 필요한 "규칙"을 좀더 확실하게 알 수 있었다는 겁니다.
당장 회사에 구현 해 둔 API들 한번 싹 점검 해야겠네요.