웹 서비스와 API > 시티즌 인사이트

본문 바로가기

시티즌 커뮤니티

시티즌 인사이트

IT&개발 정보 웹 서비스와 API

페이지 정보

작성자 GrapeCity 작성일 21-09-23 16:47 조회 155회 댓글 0건

본문

1991년 초에 공개적으로 사용 가능한 첫 번째 웹 서버가 출시되었을 때 이로 인해 얼마나 많은 일들이 있을지 아는 사람은 많지 않았습니다. 오늘날 인터넷은 이해하기 힘들 정도로 방대한 데이터 교환 고속도로이며 인터넷이 없는 일상은 상상하기 어렵습니다.

1991년 인터넷은 찾기 어려운 몇몇 웹 페이지의 집합이었으며 당시의 느린 연결 속도 때문에 해당 페이지에 접속하는 것은 더 어려웠습니다.

사람이 선별한 웹 페이지 디렉터리를 검색할 수 있는 기능인 Yahoo 검색이 1995년에 출시된 이후에도 많은 사람들은 여전히 인터넷이 무엇을 제공하는지 잘 몰랐습니다. 1998년 Google이 사람들이 현재와 같이 아주 흔하게 볼 수 있는 형태의 검색 엔진을 출시하여 자동으로 생성된 디렉터리를 사용하여 웹 전체를 서핑할 수 있었습니다.

갑자기 사람들이 AIM(AOL Instant Messenger)과 같은 이메일 및 메시징 서비스를 통해 서로 대화하기 시작했습니다. 그런 다음 Twitter와 Facebook 같은 소셜 미디어가 많은 사람들의 관심을 받았습니다. 사람들은 인터넷이 가진 힘과 인터넷이 일상적인 삶을 어떻게 변화시킬 수 있는지 이해하기 시작했습니다.

초기 인터넷 시대의 이러한 발전 중 어떤 것도 웹 서비스 및 API(응용 프로그래밍 인터페이스) 없이 가능한 것은 없습니다. 웹 서비스 및 API 모두 개발자가 서로 또는 다른 데이터 집합과 상호 작용하는 응용 프로그램을 만들도록 합니다.

웹 서비스와 API 간의 차이점은 자주 혼동되고 두 용어를 서로 바꿔 사용하는 사람들도 많습니다. 웹 서비스와 API가 관련이 있긴 하지만 동일하지 않고 개발자 입장에서는 용도가 다릅니다. 오늘 두 용어 간의 차이점과 각 서비스에 가장 잘 맞는 상황에 관해 자세히 살펴볼 것입니다.


용어의 정의

오늘의 주제를 살펴보기 전에 사용할 몇 가지 용어를 살펴보겠습니다.

  • HTTP(Hypertext Transfer Protocol)는 분산되고 협업적인 하이퍼미디어 정보 시스템을 위한 응용 프로그램 계층 프로토콜입니다.

  • XML(Extensible Markup Language)은 인간 및 기계가 읽을 수 있는 형식으로 문서를 인코딩하기 위한 규칙 집합을 정의하는 마크업 언어입니다.

  • WSDL(Web Services Description Language)XML 기반 인터페이스 기술 언어는 웹 서비스에서 제공하는 기능을 설명합니다.

  • SOAP(Simple Object Access Protocol)는 컴퓨터 간에 구조화된 정보를 교환하기 위한 XML 기반 메시징 프로토콜입니다.

  • REST(Representational State Transfer)는 World Wide Web의 설계 및 개발을 안내하기 위해 만든 소프트웨어 아키텍처 스타일입니다.

  • GRPC(gRPC Remote Procedure Calls)는 2015년 Google에서 개발한 오픈 소스 원격 프로시저 호출입니다.

  • GraphQL은 API를 위한 오픈 소스 데이터 쿼리 및 조작 언어이자 기존 데이터를 사용한 쿼리 이행을 위한 런타임 환경입니다.

  • JSON(JavaScript Object Notation)은 개방형 표준 파일 형식으로, 사람이 읽을 수 있는 텍스트를 사용하여 데이터를 저장하고 전송하는 데이터 교환 형식입니다.


웹 서비스

웹 서비스는 다른 응용 프로그램이 함께 상호 작용할 수 있도록 HTTP 인터페이스를 노출하는 응용 프로그램으로 광범위하게 정의할 수 있습니다. 그러나 좀 더 엄격하게 정의하면 웹 서비스는 WSDL, SOAP 및 XML만 노출할 수 있습니다. 이러한 정의는 REST, GraphQL 및 GRPC와 같은 다른 유형의 인터페이스를 포함하지 않기 때문에 일반적으로 오래된 것으로 인식됩니다.

간단히 말해, 웹 서비스는 다양한 네트워크 및 서버를 사용하여 시스템이 서로 통신하도록 하는 방법입니다. 웹 서비스에는 다른 컴퓨터의 요청을 수신하거나, 요청 수신 시 JSON, XML 또는 HTML 파일을 사용하여 필수 정보를 전달하는 웹 서버가 포함됩니다.

웹 서비스를 사용하려면 네트워크가 필요하다는 사실은 웹 서비스와 API 간의 본질적인 차이입니다.

일반적으로, 모든 웹 서비스는 API이지만 모든 API가 웹 서비스는 아닙니다.

웹 서비스는 소규모 내부 기간 업무 앱에서 대규모 공개 웹 API까지 그 크기와 범위가 다양합니다. AWS(Amazon Web Services), Azure, Google Cloud는 최대 규모의 공개 웹 서비스 공급자입니다. 이러한 공급자의 웹 서비스는 이상 감지번역에서 비디오 코드 변환까지 많은 작업을 하도록 합니다.

클라우드 공급업체는 단순히 웹 서비스만 제공하는 것이 아니라 VM(가상 컴퓨터), 서버리스 기능, 컨테이너를 비롯하여 다양한 방법으로 웹 서비스를 실행하도록 지원하는 인프라도 제공합니다.


API

API는 여러 소프트웨어 응용 프로그램 또는 혼합된 하드웨어-소프트웨어 메커니즘 간에 상호작용을 정의하는 인터페이스입니다. API는 보다 일반적인 개념으로, 기본적으로 응용 프로그램 또는 라이브러리가 개발자 또는 다른 응용 프로그램에 자신을 사용할 수 있도록 설정하는 데 사용하는 방법을 지칭합니다. 이러한 인터페이스가 웹 서비스의 형태를 가질 수 있지만 반드시 그런 것은 아닙니다.

웹 서비스와 API 간의 중요한 차이로 API는 오프라인 및 로컬로 사용할 수 있는 반면에 웹 서비스는 온라인으로 사용해야 한다는 점입니다. 네트워크 연결을 통하는 대신 동일한 시스템에서 API를 사용할 수 있기 때문에 일부 API의 경우 상호 작용하기 위해 네트워크가 필요하지 않습니다.

일반적으로 개발자가 API를 언급하는 경우에는 주로 인터넷을 통해 액세스할 수 있는, 웹 서비스에 훨씬 가까운 웹 API를 지칭합니다. 앞서 언급한 것처럼 다른 응용 프로그램에서는 동일한 시스템에서 Unix 소켓, 공유 파일 액세스 또는 메시지 큐를 사용하여 API를 노출할 수도 있는 데, 웹 서비스에는 해당되지 않습니다.

로컬 API의 예에는 Windows 시스템에 사용되는 COM(컴포넌트 개체 모델)이 있습니다. COM은 Microsoft에서 1993년에 처음으로 도입한 소프트웨어 컴포넌트에 대한 이진 인터페이스 표준입니다. COM에 대한 내용은 해당 문서에서 자세히 알아볼 수 있습니다.


REST API 아키텍처의 예

다음으로, 웹 서비스이자 API인 REST API의 예를 살펴보겠습니다.

컴퓨터 과학자인 Roy Fielding은 2000년 자신의 박사 학위 논문인 Architectural Styles and the Design of Network-based Software Architectures(네트워크 기반 소프트웨어 아키텍처의 아키텍처 스타일 및 설계)에서 REST 아키텍처 스타일을 정의했습니다. REST는 효율성과 액세스 가능성을 유지하기 위해 웹 서비스와 API가 어떻게 서로 상호 작용해야 하는지에 대한 제약 조건 집합을 정의합니다. REST는 도입 이후 개발자가 웹 서비스와 API를 빌드하는 방식을 안내합니다.

REST의 제약 조건을 따르는 모든 웹 서비스를 RESTful한 것으로 간주할 수 있습니다. REST 호출 요청은 웹 서비스이면서 API인 시스템을 보여주는 아주 좋은 예입니다. 네트워크를 통해 실행되기 때문에 웹 서비스이지만 동일한 시스템의 두 응용 프로그램 간에 로컬로 사용할 수도 있습니다.

REST 요청은 필수 컴포넌트 2개와 선택적 컴포넌트 3개로 구성됩니다. 필수 컴포넌트는 다음과 같습니다.

선택적 컴포넌트는 다음과 같습니다.

  • 클라이언트가 요청이 제대로 이행되었는지 확인하기 위해 서버에 전달해야 하는 추가 정보가 포함된 헤더

  • 클라이언트가 수신할 응답을 수정 및 정의하는 가변 필드를 제공하는 매개 변수

  • 서비스가 서버에 전달해야 하는 추가 정보를 제공하기 위한 본문

재미 있는 예로, 여러분이 멀티 플레이어 게임인 Rocket League에 관심이 있다고 가정해 보겠습니다. 전문 Rocket League 플레이에 대한 데이터에 액세스하기 위한 훌륭한 사이트 중 하나는 Octane.gg입니다. Octane API에 대한 호출을 만들고 플레이어에 대한 몇 가지 데이터를 요청해 보겠습니다.

REST 호출은 다음과 같이 구성됩니다.

HTTP 메서드: GET URL: https://zsr.octane.gg/players Parameters: id=3dcf-jstn

이 호출은 지정된 ID를 사용하여 전문 플레이어에 대한 기본 정보를 제공합니다.

개인 데이터베이스에 대해서는 POST 호출을 만들 수 없기 때문에 약간 더 복잡한 GET 호출을 살펴보겠습니다. 여기서는 2019 World Championship 결승전의 시합 데이터를 요청합니다.

HTTP 메서드: GET URL: https://zsr.octane.gg/stats/teams/events Parameters: stat=goals&team=23a0-nrg-esports&match=6744-nrg-esports-vs-team-vitality

reqbin과 같은 API 테스터를 사용하는 경우 이 호출의 결과가 다음과 같다는 것을 알 수 있습니다.

{  
  "stats": [{  
      "team": {  
          "_id": "6020bc70f1e4807cc70023a0",  
          "slug": "23a0-nrg-esports",  
          "name": "NRG Esports",  
          "image": "https://griffon.octane.gg/teams/nrg-esports.png"  
      },  
      "events": [{  
          "_id": "5f35882d53fbbb5894b430f9",  
          "slug": "30f9-rlcs-season-8-world-championship",  
          "name": "RLCS Season 8 World Championship",  
          "region": "INT",  
          "mode": 3,  
          "tier": "S",  
          "image": "https://griffon.octane.gg/events/rlcs.png",  
          "groups": ["rlcs", "rlcs19", "rlcs19worlds", "rlcsworlds", "rlcs8"]  
      }],  
      "players": [{  
          "_id": "5f3d8fdd95f40596eae23d6f",  
          "slug": "3d6f-garrettg",  
          "tag": "GarrettG",  
          "country": "us"  
      }, {  
          "_id": "5f3d8fdd95f40596eae23d9b",  
          "slug": "3d9b-turbopolsa",  
          "tag": "Turbopolsa",  
          "country": "se"  
      }, {  
          "_id": "5f3d8fdd95f40596eae23dcf",  
          "slug": "3dcf-jstn",  
          "tag": "jstn.",  
          "country": "us"  
      }],  
      "opponents": [{  
          "_id": "6020c370f1e4807cc702fc9c",  
          "slug": "fc9c-team-vitality",  
          "name": "Team Vitality",  
          "image": "https://griffon.octane.gg/teams/team-vitality.png"  
      }],  
      "startDate": "2019-12-15T11:01:11Z",  
      "endDate": "2019-12-15T11:49:21Z",  
      "games": {  
          "total": 7,  
          "replays": 7,  
          "wins": 4,  
          "seconds": 2193,  
          "replaySeconds": 2193  
      },  
      "matches": {  
          "total": 1,  
          "replays": 1,  
          "wins": 1  
      },  
      "stats": {  
          "goals": 14


Octane.gg는 우리가 JSON 형식으로 요청한 정보를 다시 보냅니다. JSON은 인간이 쉽게 읽을 수 있습니다. 경기가 2019년 12월 15일에 열리며 NRG eSports가 Team Vitality를 4:3으로 꺾은 것을 알 수 있습니다.

이러한 호출은 개발자가 응용 프로그램 내에서 사용할 수 있는 엄청나게 많은 정보를 제공합니다. 대부분의 API 구조는 REST API 형식과 동일하지 않다면 매우 유사합니다.

이러한 연속성은 개발자가 인터넷을 통해 웹 서비스와 상호 작용할 수 있는 확실하고 간단한 방법을 만듭니다. 개발자로서 API와 웹 서비스를 사용하여 응용 프로그램의 역량을 강화하고 필요한 데이터를 공급할 수 있습니다.


결론

요약하자면, 웹 서비스와 API는 유사한 목적을 달성하지만 서로를 구분하는 기본적인 차이가 있습니다. 웹 서비스는 항상 온라인이고 작동하기 위해서는 네트워크가 필요합니다. API는 네트워크를 통해 요청할 수 있지만 로컬에서도 만들고 사용하여 동일한 시스템에 있는 응용 프로그램이 서로 액세스하도록 할 수 있습니다.

또한 대부분의 웹 서비스가 API에 대한 클라이언트 호출의 형식을 지정하기 위해 사용하는 아키텍처인 REST도 살펴보았습니다. REST는 API 빌더와 응용 프로그램 개발자가 모두 사용할 수 있는 원활한 아키텍처를 제공합니다.

웹 서비스와 API를 통해 개발자는 오늘날 우리가 알고 사랑하는 인터넷을 만들었습니다. 때로는 파악하기 어렵지만 인터넷의 많은 부분에서 웹 서비스와 API를 통해 수많은 응용 프로그램을 지원하는 데이터와 메서드를 제공합니다.

개발자로서 이러한 두 시스템이 제공하는 이점을 활용하고, 둘의 차이점을 이해하고, 필요한 제품을 만들어야 합니다!

API 및 웹 서비스와 API 및 웹 서비스를 사용한 실험에 대해 더 자세히 알아보고 싶지만 어디서부터 시작해야 할지 모르겠으면 GrapeCity의 서비스 중 일부를 확인해 보십시오(예: React, Angular 및 Vue에서 사용할 수 있는 UI 컴포넌트 컬렉션인 Wijmo). Wijmo에는 유연하고 확장 가능한 API를 사용하여 유연한 차트 및 데이터 그리드를 만드는 기능 등 가치 있는 수많은 기능이 있습니다. Wijmo는 매우 가벼워 프로젝트에 큰 영향을 미치지 않습니다.

Wijmo 외에도 GrapeCity의 다양한 제품을 확인해 보고 싶으시다면, 그레이프시티 공식 홈페이지를 방문해 주시기 바랍니다.

  • 페이스북으로 공유
  • 트위터로  공유
  • 구글플러스로 공유
  • 카카오톡으로 보내기

댓글목록

등록된 댓글이 없습니다.

그레이프시티 홈페이지를 통해 제품에 대해서 더 자세히 알아 보세요!
홈페이지 바로가기
그레이프시티 홈페이지를 통해 제품에 대해서 더 자세히 알아 보세요!
홈페이지 바로가기
이메일 : sales-kor@grapecity.com | 전화 : 1670-0583 | 경기도 안양시 동안구 시민대로 230, B-703(관양동, 아크로타워) 그레이프시티(주) 대표자 : 허경명 | 사업자등록번호 : 123-84-00981 | 통신판매업신고번호 : 2013-경기안양-00331 Copyright ⓒ 2021 GrapeCity inc.