[아키텍처] REST와 SOAP, RESTful한 URI란?

이번 글에서 주로 다룰 내용은 REST API입니다.

글을 읽고나서 왜 REST API를 쓰는지, RESTful 한 API가 뭔지에 대해서 알게 되면, 이 글의 목적을 달성하게 된 것입니다.

 

1. SOAP

   Simple Object Access Protocol 의 약자로

   http, https, smtp 등을 통해(응용계층 프로토콜을 전송계층 프로토콜로 사용하게 해줌.) xml 기반의 메시지를 컴퓨터 네트워크 상에서 교환하는 프로토콜이다.

   SOAP Envelope 안에 SOAP Header 와 SOAP Body 가 내장되어 있으며, HTTP Header 와, MIME TYPE을 붙여서 WSDL문서(XML)를 만들고 UDDI라는 전역적 서비스 저장소에 등록한다. 이처럼 UDDI는 사용자와 서버의 중재자 역할을 한다.

   그러나 이처럼 HTTP로 전송해야할 데이터가 많고, 인/디코딩 과정도 존해하여 개발의 난이도가 높다.

2. REST

    

   Representational State Transfer 의 약자로써,

   (제가 경험한 바로는 부터 읽으시는 걸 추천!. 어차피 이해가 안 되거든요!)

   www와 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식.

   - 하이퍼미디어: 그래픽, 오디오, 영상, 텍스트, 하이퍼 링크들끼리의 상호작용

   - 소프트웨어 아키텍처(구조): SW 구성요소들 사이의 유기적 관계, 설계 지침

   내가 경험한 바로는, HTTP 기본메서드를 사용하여 데이터를 전달하는 프레임워크다. HTTP의 기본메소드는 GET/POST/DELETE/PUT/PATCH 가 있고, 이를 통해 클라이언트와 서버가 XML이나 JSON 데이터를 주고받는다. (get 은 조회, post 는 등록, delete는 삭제, put 은 전체 수정, patch 는 부분수정을 담당하는 메서드) 특히, 아키텍처다 보니 URL 명명 규칙도 명사형을 쓴다는 특징이 있다. 왜냐? 읽기 쉬우니까~ 1번 게시판을 가져와 달라는 요청을 위해 REST는 https://www.yunki.kr/board/1 를, 기존의 url은 https://www.yunki.kr/api/getBoard?board=1, 후자보다는 전자가 더 명확해보인다.

    

잠깐! SOAP와 REST의 차이

• UDDI와 같은 중간 매체 없이 고유 URL 을 통해 직접 전송하여 단순하고 빠르다.
• SOAP처럼 API를 호출하기 위해 개발환경을 셋팅할 필요가 없다.
• XML뿐만 아니라 다양한 데이터 타입을 쓸 수 있음.

 

여기는 Socker 통신부터 시작해서 오늘날의 REST에 오기까지 등장했던 주요 패러다임입니다. 별로 안 중요합니다!

3. SOA

   Service Oriented Architecture 서비스 지향 아키텍처(소아라고도 발음함)

   대규모 컴퓨터 시스템을 구축할 때의 개념으로, 시스템에 들어가는 각 기능들을 서비스로 판단하여, 이들을 조합해서 시스템 전체를 구축해 나가는 것.

   즉, 대규모 시스템 == 서비스들의 모임

4. ROA

   Resource Oriented Architecture 자원 지향 아키텍처,

   서비스를 제공하는 시스템의 리소스가 중요시 되는 구조로서 REST API가 다루는 자원들의 기반이 되는 패러다임이다.

 

잠깐! 반드시 REST여야만 할까?

GET방식이 속도가 빠르고 쉽고 간단해서 어떤 기능이든 GET을 사용하여 처리할 수도 있다. 이처럼 퍼포먼스를 신경써야하는 곳은 GET만 사용해도 좋습니다.

하지만, REST API를 구현하는 근본적인 목적은 퍼포먼스 향상이 아닌, 일관적인 컨벤션을 통한 API의 이해도 및 호환성을 높이는게 주 동기라는 사실!

Servlet 으로 개발했던 때를 생각해보자, 프론트 컨트롤러 패턴에서, 서블릿 하나가 Query String 에다가 ?cmd=delete 이런식으로 해 놓고, 백단에서는 doGet 에서 이 쿼리스트링을 조회하여 if문으로 해당 명령을 수행합니다.. 생각만해도 끔찍!

 

웹 전체적으로 봤을 때, 그들만의 방식이기 때문에 일반적이지 못하죠?

REST는 API의 이해도 및 호환성을 높이는 게 주 목적이라는 것에 명심합시다!

 

 

RESTful 한 API란?

이 번 글의 두 번째 주제입니다.

최소한 아래의 5가지 디자인에 대해서는 만족시켜야 REST API라고 합니다.

 

1. API의 Endpoint 가 오직 한 개인가?

REST 는 시스템에 존재하는 자원에 중점을 두기 때문에, 반드시 URI가 해당 자원을 구분할 수 있는 유일한 식별자(주소)가 되어야 한다.

예를들어, 영화예매의 경우, 고객, 예약번호, 좌석번호, 영화정보처럼 명사형태로 유일하게 식별할 수 있게 디자인해야한다.

2. GET/POST/DELETE/PUT/PATCH 를 각 상황에 맞게 쓰는가?

• GET: 서버로부터 데이터를 조회

• POST: 서버에 데이터를 등록

• DELETE: 서버에 존재하는 데이터 삭제

• PUT: 서버에 존재하는 데이터를 수정(완전히)

• PATCH: 서버에 존재하는 데이터를 수정(부분적으로)

   

3. 응답에 대한 메타데이터를 Body에 포함시키고 있지는 않은가?

Body에는 요청한 자원의 순수한 데이터만을 전송해야한다.

HTTP 상태코드와 같은 메타데이터는 Body에 포함시키지 말자.

 

4. URL에 동사가 포함되어 있지 않은가?

앞에서 URL에는 명사형을 사용하라고 했습니다. 다음의 예를 봅시다.

예약 상태 정보를 조회를 다음과 같아 나타냈다고 했을 때,

• /reservation/001/activate
• /reservation/001/status

전자는 이게 활성화를 시키는건지, 활성화 상태인지 의미가 모호합니다.

이처럼 동사가 포함이 되면, 행위적 표현이기 때문에 혼동이 올 수 있습니다.

반면, 후자처럼 명사형으로 확실히 지정을 해주면, 좀 더 명확하다는 장점이 있습니다.

 

5. URL에 쿼리 스트링이 포함되어 있지 않은가?

http://www.블라블라/블라블라?action=createReservation

처럼 마치 서블릿의 doGet 메서드가 model.getParameter("action") 으로 이 값이createReserveration 일 경우 createReservation() 메서드를 수행하라고 처리했던 시절처럼,

비즈니스 컴포넌트 메서드를 URL에 호출해선 안 됩니다.

다시 말하자면, REST의 설계 컨셉은 시스템에서 제공하는 자원을 식별하기 위함이기 때문입니다.

이쯤되면 자원 성애자...

 

여기까지 REST API가 무엇인지 살펴보았고, 어떠한 설계원칙을 갖고 있는지도 알아보았습니다.

스스로도 부족하다고 생각하고 있고, 시간이 나면 더 내용을 추가하고 다듬어 보겠습니다 ^^