REST API의 단점 3가지

현시대에는 많이 쓰이는 REST API도 여타 다른 기술과 마찬가지로 단점은 존재합니다. REST는 HTTP의 설계의 우수성을 살릴 수 있다는 이점이 있는 아키텍처입니다. 그렇기에 REST를 API에 도입하면 분명 단점보다는 무수히 많은 장점이 있는 게 사실입니다. 그러나 아이러니하게  REST 아키텍처의 존재 이유가 단점으로 부각되는 점 3가지가 존재합니다.

 

REST API 단점 3가지

1. 안티패턴으로 설계될 가능성이 높다.

전통적인 통신방법에도 HTTP 메서드와 Json 형식을 이용한 통신은 흔한 방식이었습니다. REST API에 대한 이해도가 떨어질 경우 단순히 통신방법이 유사하다고 "REST를 쓴다."라고 생각할 수 있습니다. 그렇기에 초창기부터 지금까지 REST API 중에는 안티패턴을 사용하는 경우가 항상 존재했습니다.

 

REST API의 안티패턴이란 REST API의 특징을 이해하지 못하고 REST 사상에 어긋나는 패턴을 적용한 API들을 말합니다. 안티패턴의 사용은 설계자의 무능함이라 볼 수 없습니다. REST 자체가 흔히 사용하는 기술을 응용하여 사용했기 때문에 설계자의 지식 기반으로 설계될 수 있습니다. 즉 틀린 지식이 아닌, 관점이 다른 지식을 사용하여 설계를 진행했기에 안티패턴이 될 가능성이 높습니다.

안티패턴의 사례 1 - HTTP Method의 잘못된 사용

최근 직접 목격한 예로는 HTTP 접근 제어 기능중 하나인 화이트리스트 방식을 사용하면서 권고 사항인 GET, POST 메서드만 사용하며 Update, Delete 기능을 POST로 대체하여 사용한 경우입니다.

/**
* 화이트리스트 설정 
*  - GET, POST 제외하고 모든 메소드 차단
*/
<security-constraint>
  <web-resource-collection>
    <web-resource-name>WhiteList_Http_Method</web-resource-name>
    <url-pattern>/*</url-pattern>
    <http-method-omission>GET</http-method-omission>
    <http-method-omission>POST</http-method-omission>
  </web-resource-collection>
</security-constraint>
    
    
/**
 * 화이트리스트 적용 전 API
 */
PUT /product/productInfo  	// 상품 정보 변경
DELETE /product/product		// 상품 삭제

/**
 * 화이트리스트 적용 전 API
 */
POST /product/product/update  	// 상품 정보 변경
POST /product/product/delete	// 상품 삭제

변경된 API는 기능상 이상은 없습니다. 그러나 REST 관점에서 두 가지 오류가 있습니다.

첫 번째로 HTTP Method를 잘못 활용했습니다. POST는 REST에서 생성의 의미를 가지고 있습니다. 그러나 POST로 갱신과 삭제의 행위를 한 것 자체가 REST라고 보기 어렵습니다.

두 번째로 자체 표현 구조(Self-descriptiveness)를 준수하지 못했습니다. REST API의 행위는 API 명과 메서드만 보고도 알 수 있어야 합니다. 그러나 위 예시에는 POST(생성)으로 갱신과, 삭제를 처리했으며, 행위가 메서드 와 API명으로 분산되어 기록되어 있어 REST의 특징 중 하나인 자체 표현 구조를 준수하지 못했습니다.

안티패턴의 사례 2 - HTTP Response code 를 2, 3개만 활용한다.

HTTP Response code는 나열하면 개수가 많기 때문에 보통은 많게는 10개, 적게는 5개 정도 사용합니다.. REST API는 HTTP를 준수하기에 이 코드들을 반환하면 클라이언트 쪽에선 에러 코드가 그대로 찍힙니다.

크롬 개발자모드에서 찍히는 요청 상태 값

에러를 싫어하는 개발자의 마음일까요? 많은 API에선 결과 코드로 성공(200)과 서비 에러(500)만 표시합니다. 에러 표현을 하기 위해 상태 값은 200으로 하고 하위 데이터 속성으로 에러 내용을 표시합니다.

// 400 에러를 표시하기 위한 결과값
{
	status : 200,
	timestamp : "2020-02-16 01:20:30",
	desc : "Bad Request!!",
	data : false
}

위 결과를 보면 400에러를 표시하기 위해 desc 필드에 문자열로 에러 명을 표시했습니다. 이러한 경우 이 API를 사용하는 클라이언트 쪽에 불필요하게 약속에 되어 있어야 하며, 클라이언트와 API와 특정 상태를 알아야 된다는 측면에서 REST의 특징인 유니폼 인터페이스(Uniform Interface)와 무상태(Stateless)를 준수하지 못했다 볼 수 있습니다.

 

2. 표준 규약이 없다.

REST는 표준이 없습니다. 그렇기에 관리가 쉽지 않습니다. 표준이 없다는 말에 이러한 생각을 할 수 있습니다.

"표준이 없는데 안티패턴인지 아닌지는 어떻게 구분하지?"

사실 안티패턴을 판단하는 근거는 REST 아키텍처의 특징을 근거로 한 암묵적은 규칙입니다. 이러한 규칙을 Defector reference 이라고도 합니다.

또한 표준이 없다 보니 성공적인 REST API 사례를 근거로 암묵적인 규칙이 생기기도 하는데 Google, Netflix, Amazone 등의 기업들이 REST의 표준역할을 하고 있습니다. 그렇다 보니 실제 REST API를 설계하는 담당자도 현 정책의 판단의 기준을 자의적으로 할 수밖에 없으며 더 안티패턴의 형태로 발전하는 경향이 있습니다.

웹 2.0의 대표라 할 수 있는 플리커(flickr)의 REST API

플리커(flickr) 서비스는 안티패턴을 가진 가장 큰 업체입니다. 위 API 명을 보면 REST라고 볼 수 없으며, 실제 사용하는 HTTP Method는 GET과 POST만 사용합니다. 그렇다고 플리커의 API가 틀렸다고 볼 수 없습니다. 표준이 없으니 틀렸다 할 근거가 없습니다.

Flickr 서비스

비표준 REST API 설계와 관리를 어떻게 해야 할까요? 

비표준에서 오는 관리의 문제점은, 제대로 된 REST API 표준 가이드와, API 개발 전후로 API 문서를 제대로 만들어서 리뷰하는 프로세스를 갖추는 방법으로 해결하는 방법이 현재로서는 가장 좋은 방법입니다. 

제대로 된 REST API 가이드는 성공한 REST API의 사례가 되는 기업의 예시를 기준으로 만들며, 많은 사람들에게 리뷰에 규칙에 대한 객관성을 마련해야 합니다. 

 

3. RDBMS의 표현에 적합하지 않다.

RDBMS는 다양한 키들이 존재합니다. REST API는 리소스를 표현할 때 나열하기 용의한 형태 (Json, XML...)를 사용하기 때문에 RDBMS에 표현이 적합하지 않을 수 있습니다. 

// memberSeq = 123의 조회 결과
{
	status : 200,
	timestamp : "2020-02-16 01:20:30",
	desc : "success",
	data : {
 		memberSeq : 123,
		memberInfo : {
			age : 29,
			name : "kim"
		}
		privateInfo : {
			phoneNumber : "010-0000-0000",
			email : "abc@googles.com"
		}
	}	
}

회원 기본정보, 회원의 개인정보는 서로 다른 테이블에 존재하며 FK를 통해 서로 묶여 있다고 가정하겠습니다. 위와 같은 하나의 나열 데이터로 만들기 위해선 각각의 테이블을 조인하거나 서버가 다를 경우 각각 조회하여 Json 문으로 만들어야 합니다. 만약 1건이 아니라 다수 건일 경우 처리 시간은 데이터에 비례적으로 커질 것입니다. 

그래서 근래의 DB중 mongoDB나 CouchDB처럼 Json 형태 그대로 사용할 수 있는 DB를 사용하거나, 리스크를 극복하기 위한 다양한 아키텍처가 나오고 있습니다.

 

좋은 사례로 구글의 경우 Alternative Key를 사용하거나, 링크 방식 사용을 권장하고 있습니다

API design: Why you should use links, not keys, to represent relationships in APIs | Google Cloud Blog

 

참고자료

https://round-round.tistory.com/6

https://bcho.tistory.com/954

https://cloud.google.com/blog/products/application-development/api-design-why-you-should-use-links-not-keys-to-represent-relationships-in-apis

https://www.flickr.com/services/api/