RESTful API

이번 포스팅에서는 애플리케이션을 설계할 때 한번쯤은 들어봤을 법한 단어인 RESTful에 대해서 알아보도록 하겠습니다. 

 

RESTful API는 현재 많은 애플리케이션에서 사용하고있는 설계방식으로서 이번 시간에는 왜 RESTful이 이렇게 인기가 좋은지, 단점은 뭐가 있는지에 대해서 알아볼겁니다. 

 

RESTful이라는 단어는 직역하면 "REST한" 정도로 해석할 수 있을 것 같네요 즉 REST한 API라고 볼 수 있습니다. 걸리는게 두가지 있네요 REST와 API, 이 두가지에 대해서 설명해야겠죠?

 

먼저 간단한 API에 대해 알아보고 REST에 대해 자세히 알아보겠습니다.

 

API

API란 데이터와 기능의 집합을 제공하여 컴퓨터 프로그램간 상호작용을 촉진하며, 서로 정보를 교환 가능하도록 하는 것입니다. 

 

위의 정의는 너무 사전적인 의미라 잘 이해하기 힘드니까 좀 풀어서 설명하자면

 

"상호간 데이터를 가공하기위해 보내는 요청" 정도로 해석할 수 있습니다. 예시를 보여드리자면

 

이런 각각의 요청들을 API라고 할 수 있겠습니다. 

 

API는 뭐 간단하니까요 설명은 이정도만 해도 충분할 것 같습니다. 

 

 

REST

REST에 들어가기 앞서 우리는 한가지 요구사항을 들어줄겁니다. 

 

요구사항 : 회원 정보 관리 API를 만들어라

 

• 회원 목록 조회
• 회원 조회
• 회원 등록
• 회원 수정
• 회원 삭제

우리는 이 다섯가지 API를 만들어야합니다. 

 

가장 간단한 방법은 이렇게 만드는거죠

 

• 회원 목록 조회 = /read-member-list
• 회원 조회 = /read-member-by-id
• 회원 등록 = /create-member
• 회원 수정 = /update-member
• 회원 삭제 = /delete member

자 원하던 API를 만들었습니다. 

 

흠... 이게 과연 좋은 URI 설계일까요?

 

URI를 설계할 때 가장 중요한 것은 바로 리소스 식별 입니다. 

 

리소스의 의미는 뭘까요? 

 

회원을 등록하고 수정하고 조회하는 것이 리소스가 아닙니다. 예를 들어서 미네랄을 캐라! 라고 하면 미네랄이 바로 리소스가 되는 것입니다. 캐라! 가 리소스가 아니란 말이죠

 

그럼 위의 예제에서는 "회원"이 리소스가 될 것입니다. 

 

URI에서는 리소스만 식별하면 되기 때문에 "회원"이라는 리소스를 URI에 매핑해야 합니다. 

 

그럼 이제 제대로 설계해보죠

 

• 회원 목록 조회 = /members
• 회원 조회 = /members/{id}
• 회원 등록 = /members/{id}
• 회원 수정 = /members/{id}
• 회원 삭제 = /members/{id}

음... 이렇게 리소스에 집중해서 URI에 매핑했더니 문제가 발생했습니다. 회원 조회, 등록, 수정, 삭제를 어떻게 구분할지 모르겠습니다. 

 

위에서 URI를 설계할 때 가장 중요한 것은 리소스를 식별하는 것이라고 했습니다. URI는 리소스만 식별하고 해당 리소스를 대상으로 하는 행위를 분리하면 됩니다. 

 

그럼 행위는 어떻게 구분할까요? 

 

이때 등장하는게 바로 HTTP Method입니다. 

 

RESTful에서 자주 사용하는 HTTP 메서드가 있습니다. 바로 GET, POST, PUT, PATCH, DELETE 이렇게 다섯가지입니다. 

 

GET과 POST는 익숙하시죠? 애플리케이션을 설계할 때 데이터를 요청, 데이터를 삽입할 때 많이 사용하던 메서드입니다. 그래서 스프링에서 @GetMapping, @PostMapping 이렇게 지원하고 있구요. 

 

간단하니까 빠르게 정리하고 넘어가도록 하겠습니다. 

 

• GET : 리소스 조회 (CRUD 에서 R)
• POST : 요청 데이터 처리, 주로 등록에 사용 (CRUD에서 C)
• PUT : 리소스를 대체, 해당 리소스가 없으면 생성 (CRUD에서 C, U)
• PATCH : 리소스 부분 변경 (CRUD에서 U)
• DELETE : 리소스 삭제 (CRUD에서 D)

GET과 POST는 익숙하고 DELETE는 대충 어떤 느낌인지 알겠는데 PUT과 PATCH가 좀 신경쓰이시죠?

 

짤막하게 설명하고 넘어가보겠습니다. 

 

PUT은 리소스를 대체하는 것입니다. 그리고 리소스가 없으면 생성하죠

 

만약 username, age 라는 필드가 두개 있는 user 라는 객체가 있다고 가정해봅시다. 

 

*기존

username : 철수

age : 20

 

*PUT 요청으로 username을 영희로 변경

username : 영희

 

PUT은 리소스가 없으면 생성하는 것은 둘째치고 만약 있으면 해당 값을 덮어씌워버립니다. 때문에 나는 username만 바꾸고 싶은데? 하면 PUT을 사용할 수 없습니다. 

 

이런 문제를 해결하기위해 나온 메서드가 바로 PATCH입니다. 

 

*기존 

username : 철수

age : 20

 

*PATCH 요청으로 username을 영희로 변경

username : 영희

age : 20

 

이렇게 부분적으로만 바꿀 수 있게 도와주는 메서드가 바로 PATCH입니다. 

 

자 그럼 이제 URI를 다시 설계해볼까요?

 

• 회원 목록 조회 = GET : /members
• 회원 조회 = GET : /members/{id}
• 회원 등록 = POST : /members/{id}
• 회원 수정 = PUT 혹은 PATCH : /members/{id}
• 회원 삭제 = DELETE : /members/{id}

이제 행위와 리소스를 분리함으로써 완벽하게 설계했습니다. 

 

근데 우리 REST 설명하려던거 아니었나요? 

 

제가 지금까지 HTTP 메서드를 설명하면서 설계한 방식이 바로 RESTful입니다. 

 

별로 어렵지 않으시죠? 정리하면 "행위(HTTP Method)와 리소스로 URI를 설계하여 상호간 데이터를 가공하기 위한 요청"이 바로 RESTful API인 것이죠 

 

 

이런 RESTful API가 왜 인기가 많을까요?

 

RESTful API의 장/단점

장점

• HTTP 프로토콜의 인프라를 그대로 사용하므로 RESTful API를 위한 별도의 인프라를 구축할 필요가 없다.
• HTTP 프로토콜의 표준을 그대로 따르기 때문에 HTTP가 가지는 장점을 그대로 가진다. 
• HTTP 표준 프로토콜을 따르는 모든 플랫폼에서 사용이 가능하다. 
• REST API 메세지가 의도하는 바를 명확하게 나타내므로 의도하는 바를  쉽게 파악할 수 있다. 
• 서버와 클라이언ㅇ트의 역할을 명확하게 분리한다. 

오우...장점이 하나같이 강력하네요 이래서 RESTful을 많이 사용하나봅니다. 하지만 장점이 있으면 단점도 있겠죠? 단점도 한번 알아보죠

 

단점

• 표준 자체가 존재하지 않아서 정의가 필요하다.
• HTTP 메서드 형태가 제한적이다.
• 구형 브라우저에서 호환이 되지 않아 지원해주지 못하는 동작이 많다. 
• 유연하지 못한 특징이 있다.

마지막 단점이 좀 크리티컬합니다. 사실 앞에 세가지는 단점이긴 하지만 그렇게 중요하지는 않습니다. 

 

RESTful의 큰 단점이라고 꼽히는 유연하지 못한 특징은 이런 느낌입니다. 

 

ex) A팀에 속한 "철수"라는 멤버가 구매한 옷

자...위에 있는 데이터를 가지고 오기 위해 API를 설계해봅시다. 

 

/team/A/members/철수/buy/shirt 

와... 엄청 기네요? 자 이제 이 API를 날리면 뭐가 나오죠? 철수가 구매한 옷 정보가 나오겠죠? 

 

근데 갑자기 요구사항이 추가됩니다. "철수가 구매한 신발에 대한 정보가 필요할 것 같아요"

 

그럼 이렇게 해야죠

/team/A/members/철수/buy/shoes

 

자 이제 이러면 되는거죠? 

 

근데 또 요구사항이 늘어납니다. 그렇게 또...또...또...또...

 

요구사항이 늘어날때마다 API가 계속해서 추가되어야 합니다. 이거 유지보수 하기 쉽지않겠죠... 

 

이 문제는 RESTful API에서는 해결할 수 없는 문제입니다. 

 

하지만 이런 문제가 있더라도 RESTful만의 강력한 장점으로 인하여 단점이 좀 묻히는 경향이 있습니다. 이 문제를 해결하기 위해 GraphQL 이라는 API가 나오긴 했는데 이건 또 포스팅 하나 분량이기 때문에 다음 포스팅으로 미루도록 하겠습니다. 

 

 

자 이렇게 RESTful API에 대해서 알아봤습니다. 어떤가요? 저는 공부하면서 그렇게 크게 어려운 부분을 못느꼈던 것 같습니다. 쉽지만 중요한 개념이다보니 이렇게 정리해봤네요. 

 

다음엔 GraphQL에 대해 포스팅해볼 예정입니다. 방문해주셔서 감사하고 오늘도 즐거운 하루 보내세요!