[API] API 종류 - SOAP vs REST vs GraphQL

프로그램을 개발하다보면 API를 호출하여 서버의 데이터를 가져오거나, 데이터 처리를 요청한다. 나도 여러가지 프로젝트를 하면서 SOAP 이나 RESTful API를 개발해보기도 하고 호출하기도 했는데, 방식의 차이점을 정확하게 알지는 못했다. freeCodeCamp 에서 이를 설명해주는 글이 있어 정리해보려고 한다. 영어로 된 문서라 해석이 잘못될 수도 있다. 😅

---

Intro

Client-Server 모델에서 API는 매우 중요하다!
간단하게 말하면, Client-Server 모델은 Requester인 Client가 Provider인 Server에 서비스나 리소스를 요청하는 방식이다. 요청을 받은 Server는 Client가 원하는 정보를 제공하거나 Action을 한다.
대부분의 요즘 어플리케이션들은 Client-Server 모델을 사용하는데, Client와 Server가 커뮤니케이션을 하기 위한 방법이 API이다!

API : Application Programming Interface

• API는 서로 통신하기 위한 규칙을 정의하고 있다. (Ex: A를 보내면 B를 응답한다. C를 보내면 D를 응답한다 와 같은..)
  -> 규칙이 있기에 Client와 Server는 서로가 무엇을 원하는지 명확하게 알 수 있다.
• 현재 모든 애플리케이션은 API를 사용하고 있다.API를 구현하기 위한 방법
• 최근 가장 많이 쓰이는 방식
  • REST
  • GraphQL
• 약간 옛날 방식
  • SOAP

SOAP API

SOAP : Simple Object Access Protocol

• 다른 시스템이 인터넷을 통해 구조화된 데이터를 교환하기 위한 메시징 프로토콜
• XML 기반의 프로토콜
• 1998년에 Microsoft가 소개함
• 플랫폼에 독립적인 방식으로 (platform-independent way) 인터넷을 통해 데이터를 교환하기 위해 설계되었다.
• 2003년에 World Wide Web Consortium(W3C) 에 의해 표준화됨

주요 특징

1. 프로토콜에 독립적 : SOAP은 HTTP, SMTP, FTP을 포함한 인터넷을 통한 메세지 전송을 지원하는 모든 프로토콜에서 동작한다.
2. 플랫폼에 독립적 : SOAP은 XML을 지원하고 HTTP 메세지 송수신을 할 수 있는 모든 프로그래밍 언어나 플랫폼에서 동작하도록 설계되었다.
3. 메세징 : SOAP 은 메세징 프로토콜이다. 다른 시스템 간에 구조화된 데이터를 교환하기 위한 규칙을 정의한다.
4. 보안 : SOAP은 암호화, 디지털 서명, 인증 등의 보안 표준을 지원한다.
5. 확장성 : SOAP 은 특별한 요구사항을 지원하기 위해서 사용자 지정 확장자을 만드는 것을 허용한다.

장점

1. 표준화 : SOAP은 잘 표준화된 프로토콜이므로 서로 다른 시스템 간 신뢰있는 데이터 교환이 가능하다.
2. 보안 : 기본적으로 보안 표준을 지원하기 때문에 중요한 데이터 전송에 적합하다.
3. 확장성 : 높은 확장성을 가지고 있으며 특별한 요구사항을 위한 사용자 지정 확장자 만드는 것을 지원한다.

단점

1. 복잡성 : SOAP은 구현하기 복잡할 수 있고, 전문지식이 필요할 수 있다.
2. 오버헤드 : SOAP메세지가 클 수 있고, 상당한 처리 리소스가 필요할 수 있기 때문에 오버헤드가 증가한다.
3. 성능 : SOAP의 메세징 특성 때문에 타 API 프로토콜에 비해 느릴 수 있다.

SOAP을 적용하는 경우

1. 민감한 데이터를 전송해야할 때 : SOAP은 보안 표준을 제공하기 때문에 민감한 데이터를 교환하는데 적합하다.
2. 복잡한 데이터 구조를 지원해야 할 때 : SOAP은 복잡한 데이터 구조를 지원한다.
3. 신뢰성 있고 표준화된 프로토콜을 사용해야할 때 : 잘 정립되어있고 표준화되어있는 프로그램이기 때문에 신뢰성있는 통신을 지원한다.

적용 산업

• SOAP API는 웹 서비스 초반에 널리 쓰였던 프로토콜이며, 현재도 일부 산업군에서 쓰이고 있다. (비록 REST나 GraphQL이 요즘 대세 일지라도..)

1. 헬스케어 산업 : SOAP은 헬스케어 어플리케이션을 위해 사용된다. 건강 데이터 (Electronical Health Records, EHR), (Health Information Exchanges, HIE) -> 민감한 데이터이기 때문에 보안 표준을 제공하는 SOAP 프로토콜을 사용한다.
2. 금융 : 금융데이터는 안전하고 신뢰할 수 있는 방식으로 전송되어야하기 때문에 결제 게이트웨이나 거래 플랫폼과 같은 금융 어플리케이션에서 사용된다.
3. 기업용 어플리케이션 : 데이터 교환을 위해 표준화, 안정화되어있기 때문에 CRM이나 ERP시스템과 같은 기업용 어플리케이션에서 사용된다.
4. 레거시 시스템 : 오래된 시스템과 어플리케이션을 여전히 SOAP API를 사용한다. 따라서 이를 마이그레이션 하는데 비용과 시간이 많이 소요될 수 있다...

SOAP API 사용하는 방법

XML : Tag를 정의해서 데이터의 구조와 내용을 설명 (<name>김유민</name>)

• 프론트엔드 > HTTP 요청메세지를 전송
  • URL : SOAP API URL
  • Content-Type : 'text/xml'
  • Body : SOAP Message -> XML 형태
• 👉 응답받은 메세지도 XML 형태이며, 이를 사용하기 위해 Parsing 해서 요소값을 추출해야한다.
• Javascript 예시 

const parser = new DOMParser();
const xmlDoc = parser.parseFromString(xml, 'text/xml'); // xml 파싱
const value = xmlDoc.getElementsByTagName('Value')[0].childNodes[0].nodeValue; // Value 태그의 첫번째 요소의 값을 가져옴
console.log(value);

👉 다소 복잡하다!

REST API

REST : Representational State Transfer

• 웹 서비스 및 API 구현에 널리 사용되는 아키텍쳐 스타일
• 2000년에 Roy Fielding 에 의해 처음 공개 (HTTP 프로토콜의 주요 저자 중 한명)
• RESTful API는 간단하고, 확장성있고, 유연하도록 설계됨
• 웹, 모바일, IoT, 마이크로서비스 아키텍쳐 서비스 등 다양한 곳에서 사용

주요 특징

1. 상태가 없음(stateless) : REST API는 상태를 저장하지 않는다. 따라서 각 Request 메세지는 처리에 필요한 모든 정보를 포함한다. 이렇게 하면 서버에서 세션 데이터를 저장하고 관리할 필요가 없기 때문에 API 확장이 더 쉬워지고 성능이 향상된다.
2. 리소스 기반 : 각 리소스는 고유한 URI (Unique Resource Identifier)로 식별되며, GET/POST/PUT/DELETE 와 같은 메소드로 리소스에 엑세스를 할 수 있다.
3. 균일한 인터페이스 : 클라이언트가 표준화된 메서드와 응답 형식을 사용하여 리소스와 상호작용 할 수 있는 균일한 인터페이스를 가진다. 따라서 서버 개발자는 API를 더욱 쉽게 구축하고 유지관리 할 수 있고, Client는 쉽게 사용할 수 있다.
4. 캐싱 가능 : REST API는 캐싱을 통해 성능을 개선하고 네트워크 트래픽을 줄일 수 있다.
5. 계층화된(Layered) 시스템 : 계층화되도록 설계되어있어 전체 시스템에 영향을 주지 않고 클라이언트와 서버 사이의 프록시/게이트웨이와 같은 중개자를 추가할 수 있다.

장점

1. 배우고 사용하기 쉽다.
2. 확장성 : stateless 하기 때문에 높은 확장성과 효율성을 가진다!
3. 유연성 : 유연하기 때문에 넓은 범위의 어플리케이션과 시스템에 적용될 수 있다.
4. 광범위한 지원 : REST API는 개발 도구와 프레임워크에서 광범위하게 지원하므로 기존의 시스템에 쉽게 통합할 수 있다.

단점

1. 표준 부족 : 불일치 및 상호운용성 문제가 발생할 수 있다.
2. 제한된 기능 : 간단한 요청 및 응답을 처리하도록 설계되어있기 때문에 복잡한 경우 적합하지 않을 수 있다.
3. 보안 문제 : 제대로 구현되지 않는 경우 XSS나 CSRF 공격에 취약할 수 있다.

REST API 적용하는 경우

• 웹, 모바일 애플리케이션, 마이크로서비스 아키텍쳐, IoT 시스템 구축에 매우 적합
• 확장성, 유연성이 중요한 경우 & 기존 시스템 및 기술과 통합해야하는 경우에 특히 유용
  👉 단순, 확장가능, 유연하기 때문에 웹서비스와 API 구축에 널리 사용된다!

REST API 사용하는 방법

• REST API 응답 : JSON 또는 XML 형식, HTTP 상태코드를 사용해 요청의 성공.실패를 나타냄

GraphQL

• 2012년 Facebook 에서 개발한 API용 쿼리언어, 2015년에 대중에 공개
• REST API의 대안책으로 인기 얻음
• GraphQL은 Facebook의 모바일 어플리케이션의 데이터 패치를 단순화하기 위해 만들어짐 (성능 이슈를 유발하는 복잡한 데이터 요청을 해결하기 위해 GraphQL 개발)
• 2015년에 오픈 소스 프로젝트로 공개되었고, 현재는 많은 개발 도구와 프레임워크가 존재 (아폴로, Prisma, Hasura 등)

주요 특징

1. 강력한 DataType : 각 필드에 특정 데이터 Type이 있기 때문에 Client와 Server는 데이터를 더 쉽게 검증하고 처리할 수 있다.
2. 쿼리 언어 : Client가 필요한 데이터를 정확히 지정할 수 있는 자체 쿼리 언어가 존재한다. 오버패칭을 줄여 성능이 향상된다.
3. 단일 EndPoint : GraphQL은 단일 엔드포인트가 있기 때문에, 하나의 요청에서 필요한 모든 데이터를 가져올 수 있다.
4. 선언적 : Client는 원하는 것을 얻는 방법이 아니라 원하는 것을 지정하기 때문에 보다 효율적이고 유연하게 데이터를 가져올 수 있다.
5. 스키마 기반 : 스키마가 데이터 구조와 사용 가능한 쿼리와 변형을 정의한다. 따라서 개발자는 API를 더 쉽게 이해하고 작업할 수 있다.

장점

1. 효율적인 데이터 가져오기 : Client가 필요한 데이터만 가져올 수 있기 때문에 과도하게 데이터를 가져오지 않아 성능을 향상시킬 수 있다.
2. 강력한 Type : GraphQL은 강력한 Type을 가지고 있기 때문에 데이터를 검증하고 처리하기 쉽다.
3. 단일 엔드포인트 : 단일 엔드포일트로 API의 복잡성을 줄여 작업을 쉽게 만든다.
4. 스키마 기반 : 스키마 기반이기 때문에 API를 이해하기 쉽다.

단점

1. 복잡하다. : REST API에 비해 설정과 작업이 더 복잡하다.
2. 캐싱 : API의 유연성 때문에 GraphQL의 캐싱이 보다 어렵다.
3. 학습 곡선 (Learning Curve) : 자체 쿼리언어와 데이터 패칭 방식이 있기 때문에 학습 곡선이 존재한다. (특정 기술을 배우고 실제 업무에 적용하기 위해 드는 학습 비용이 필요하다.)

GraphQL API 적용하는 경우

1. 효율적이고 유연한 요구 사항 : 모바일이나 웹 어플리케이션과 같이 효율적이고 유연한 데이터 패칭을 요구하는 경우에 적합하다.
2. 복잡한 데이터 요구 : 복잡한 데이터를 요구하고 오버패칭으로 인한 성능 이슈가 우려되는 경우에 적합하다.

GraphQL API 사용하는 방법

• Request :
  • body JSON 형태, query 항목에 원하는 데이터를 명시

  • fetch('https://api.example.com/graphql', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
    query: `
      query {
        user(id: 123) {
          name
          email
          posts {
            title
          }
        }
      }
    `
    })
    })
    .then(response => response.json())
    .then(data => {
    console.log(data);
    // Access the values within the response here
    })
    .catch(error => console.error(error));

    👉 user id 가 123인 user 정보 (name, email, post의 title) 요청
• Response : data에 Client가 원하는 데이터를 담아서 Return

  {
  "data": {
    "user": {
      "name": "John Doe",
      "email": "john.doe@example.com",
      "posts": [
        { "title": "Post 1" },
        { "title": "Post 2" }
      ]
    }
  }
  }

  👉 data.user.name OR data['user']['name'] 으로 user id 가 123인 user의 name에 접근 가능

💡 GraphQL은 Client가 원하는 데이터를 보다 명확하게 요청할 수 있으므로, 불필요한 데이터 수신을 줄일 수 있다. 때문에 성능향상을 기대할 수 있다.

• 유연성, 효율성, 사용성을 고려하면 모던 웹 어플리케이션에 적합하다!

그럼 내가 제일 자주 쓴 WCF SERVICE는 뭐지?

WCF : Windows Communication Foundation
이번 게시물을 쓸 때 공부한 freecodecamp의 게시물에서는 GraphQL 까지만 소개하고 끝난다.
전 회사에서 근무할 때, .NET Framework 를 사용하여 윈도우 응용프로그램이나 ASP.NET으로 웹사이트를 개발할 때, 서버의 데이터를 사용하기 위해 WCF Service를 참조하였다. 정말 잘 사용했었는데 정작 WCF가 뭔지 잘 모르고 사용했던 것 같아서 잠깐 알아보고 이 게시물을 끝내려고 한다.

WCF

• 응용프로그램, 서비스 등이 다른 컴퓨터와의 통신을 쉽게 구현할 수 있도록 해주는 프레임워크
• Microsoft에서 서비스 지향 애플리케이션(Service Oriented Application) 구현 시 사용할 수 있도록 개발
  • 프로젝트에서 서비스 참조 추가 > 참조할 웹서비스의 URL를 입력하여 서비스를 참조(호출) 할 수 있었다.
  • 그리고 백엔드는 WCF Service 프로젝트에서 구현하고 빌드하여 IIS에 배포했다.

특징

1. 서비스 지향성 : SOA(Service Oriented Architecture)방식으로 애플리케이션이 서로 하드코딩되지 않아 느슨하게 결합된 관계이기 대문에 모든 클라이언트가 어떤 서비스에나 연결할 수 있다.
2. 보안 : 메세지를 암호화할 수 있으며 사용자가 인증을 해야 메세지를 받을 수 있도록 지정할 수 있다. 또한 SSL이나 WS-SecureConversation을 적용할 수 있다.
3. 다양한 전송 및 인코딩 : 다양한 프로토콜과 인코딩을 사용하여 메세지를 전달할 수 있다. 주로 HTTP를 사용하여 SOAP 메세지를 보낸다. 제공되는 방법 중 적합한 항목이 없는 경우에는 사용자 지정 전송,인코딩 방식을 직접 정의할 수 있다.
4. AJAX 및 REST 지원 : SOAP방식의 XML 뿐만 아니라 일반적인 XML 데이터도 처리할 수 있도록 구성할 수 있다. JSON 과 같은 비XML 형식도 지원할 수 있도록 확장가능하다.
   등.. 여러 특징이 있다.

방법

1. 서비스 계약 인터페이스 정의 : interface 파일에 [OperationContract]특성을 가진 작업을 선언
2. 서비스 계약 구현 : class 파일에 서비스 계약을 구현한다. > 각 메서드가 처리할 내용을 구현한다.
3. app.config 편집 : app.config 파일에 <service>, <add>, <endpoint> 행을 추가해야 한다. 자세한 내용은 - 참고
4. 빌드
   (WCF 서비스를 만드는 방법은 길지만 해당 내용을 다루는 포스팅이 아니기 때문에 간결하게만 짚고 넘어가도록 하겠다..!)

전회사에 근무한 것도 꽤 오래돼서 기억은 잘 안나지만, 같은 .NET 계열인 프로젝트에서는 서비스를 SOAP 방식으로 선언하여 참조했다. 마치 같은 프로젝트에 선언되어있는 메서드처럼 메서드 호출하듯이 호출하여 서버의 데이터를 사용했다. 모바일 어플리케이션를 구현할 때는 웹서비스의 응답을 JSON으로 받아 처리할 수 있어야했다. 따라서 WCF 서비스를 REST 방식으로 선언하여 REST API를 HTTP 메세지를 통해 호출했다.
WCF 프로젝트로 다양한 방식의 API를 만들고 호출할 수 있었던 게 WCF의 확장성 덕분이었다!
추억이 새록새록.. 재밌었는데...

---

 

 

해당 게시글에 문제가 있을 경우 댓글 남겨주시길 바랍니다. 읽어주셔서 감사합니다.

참고 : https://www.freecodecamp.org/news/rest-vs-graphql-apis/