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는 공개하지 않거나 사용...