REST가 SOAP을 밀어내고 Web API의 실질적 표준으로

아래 그림은 New Job Requirement: Experience Building RESTful APIs 라는 기사에서 인용해온 것입니다.

출처 : New Job Requirement: Experience Building RESTful APIs

Web API로 제공되는 프로토콜의 추세를 보여주는 그림으로 이미 2008년에도 REST가 SOAP의 두 배 이상을 제공하고 있었지나 지금은 다섯 배에 가까운 비중을 차지하므로, 대부분의 신규 웹 API들은 REST 기반이라고 읽을 수 있습니다.

SAAS(Software as a Service)의 대명사라고 할 수 있는 Salesforce.com은 SOAP API 기반의 웹서비스로 구축되어 있었는데 최근에 REST API를 제공하기로 결정했다고 합니다.

개인적으로는  2003년부터 SOAP을 직접 XML 파싱하여 처리하면서 성능이나 효율을 높이기 위해 고심을 했었는데, 결과적으로 스펙이 처리 성능을 전혀 고려하지 않았다는 심증을 굳히곤 했습니다.

SOAP은 불필요한 envelope을 원본 데이터 XML 위를 감싸고 또 뜯어내는 처리를 필요로 합니다. 대부분의 경우 별도의 의미를 갖지 않음에도 불구하고 만들어진 XML 문서를 다시 envelope의 body 부에 끼워넣고 또 발라내는 작업을 해야 합니다. API 호출 빈도가 높아질수록 가벼운 API가 점점 더 성능의 한계로 다가오게 됩니다.

개인적으로는 XML도 성능 관점에서 선호하지 않는 편인데요, 특히 namespace 덕분에 프로세싱에 부담을 주는 XML의 발전 방식은 불필요한 무거움 자체입니다. ns 표준을 프로세싱을 전혀 신경 안쓰고 정하는 것이 맞을까?

API들은 분산 환경에도 불구하고 상당히 상세한 수준에서 open되어 하나의 기능을 위해 매우 많이 호출되는 경우도 많습니다. 전통적으로 원격 통신을 하는 방법은 상위 수준의 API만 노출하고 빈번하게 호출될 가능성이 높은 하위 수준의 세세한 API는 공개하지 않거나 사용을 줄일 수 있도록 다른 방법을 제공하게 되는 편인데, 최근의 Web API는 하나의 클라이언트 로직에서 빈번하게 호출되는 경우도 발생하는 것 같습니다.

이런 경우에 별다른 semantic을 갖지 않은 soap envelope과 xml namespace 형식 자체가 가지는 오버헤드는 불필요한 낭비일 뿐입니다.

물론 payload로부터 meta data를 분리 표현하기 위한 soap header와 문서의 scope을 지정하기 위한 namespace가 전혀 의미가 없지는 않겠지만, 대부분의 soap header 는 아래 http와 같은 transport layer의 binding으로도 처리할 수 있지 않을까 생각해봅니다.

xml namespace도 prefix를 element 이름 앞에 ':'을 사용하여 붙일 것이 아니라 별도의 attribute로 처리했으면 훨씬 XML 파싱과 노드 처리가 효율적이 되지 않았을까 생각해봅니다.

그외에도 XML 문서를 표현하는 DOM 표준에 사용된 자료 구조가 단순 트리 구조라서 노드 검색이 매우 비효율적인 부분도 많이 아쉬웠습니다. getElementById 를 제외하면 노드에 random access를 제공하는 API가 없고, 각 자식 노드 이름들을 일일이 비교해서 찾아야 하는데요. 게다가 getElementById조차도 namespace 표준에서는 xml:id를 특별하게 취급해도록 정의하고 있지요.

전통적인 WS-* 스펙에서 SOAP과 xml namespace는 계속 의미를 가지겠지만, 여전히 제한적일테고 기업 환경에 WS-* 스펙 도입이 주는 효과 역시 계속 한계가 있을 것입니다. 기존의 RPC 패러다임을 WS-* 스펙으로 대체하고 난 다음에 구현에 따라 각 기업이 지불해야 할 하드웨어 비용이 열 배 이상 되는 경우를 가끔 봅니다.

하드웨어는 끊임없이 가격이 싸지고, 처리 용량이 늘어나지만, 소프트웨어가 처리해야 할 정보 양 또한 폭발적으로 늘어납니다.

논리 모델은 이상적으로 정의하더라도 구체적인 표준 정의는 처리 성능도 고려해야 하지 않을까요?