웹 서비스 및 API

1991년 초, 처음으로 공개적으로 사용할 수 있는 웹 서버가 출시되었을 때, 앞으로 무슨 일이 일어날지 아는 사람은 드물었다.오늘날 인터넷은 이해할 수 없는 거대한 데이터 교환 고속도로이다. 인터넷이 없으면 우리의 삶이 도전이라고 상상하는 것은 도전이다.
그러나 1991년에는 몇 개의 웹 페이지의 집합일 뿐 찾기가 어려웠고, 그 시대의 연결 속도가 느려서 방문하기가 더욱 어려웠다.
1995년 야후 검색(Yahoo Search)이 출시된 후에도 많은 사람들이 인터넷이 무엇을 제공할 수 있는지 확신하지 못한다. 야후 검색은 사람들이 인공적으로 관리하는 웹 디렉터리를 검색할 수 있게 한다.1998년에 구글은 현재 어디에도 없는 검색엔진을 출시하여 사람들이 자동으로 생성된 디렉터리를 사용하여 전체 네트워크를 조회할 수 있게 했다.
갑자기 사람들은 이메일과 미국 온라인 메신저(AIM) 등 정보 서비스를 통해 서로 이야기를 나누기 시작했다.그러자 트위터와 페이스북 등 소셜미디어가 많은 이들의 관심사로 떠올랐다.사람들은 이 도구의 힘과 일상생활을 어떻게 바꾸는지 이해하기 시작했다.
만약 웹 서비스와 응용 프로그램 프로그래밍 인터페이스 (API) 가 없었다면 초기 인터넷 시대의 모든 이러한 발전은 불가능했을 것이다.웹 서비스와 API는 개발자가 서로 상호작용하거나 서로 다른 데이터 집합을 만드는 응용 프로그램을 만들 수 있도록 한다.
웹 서비스와 API 사이의 차이는 종종 사람을 곤혹스럽게 하는데, 많은 사람들이 이 두 용어를 잘못 바꾸어 사용한다.웹 서비스와 API는 관련이 있지만 개발자에게 서로 다른 용도를 제공한다.오늘 우리는 이 두 서비스 간의 차이점과 어떤 상황이 각 서비스에 가장 적합한지 깊이 있게 연구할 것이다.

용어의 정의
오늘의 주제에 대해 심도 있게 토론하기 전에 우리가 사용할 용어들을 살펴보자.

하이퍼텍스트 전송 프로토콜(HTTP)은 분포식, 협업식 하이퍼미디어 정보 시스템의 응용층 프로토콜이다.

확장 가능한 태그 언어(XML)는 사용자가 읽을 수 있는 형식으로 문서를 인코딩하는 데 사용되는 규칙을 정의하는 태그 언어이다.

웹 서비스 설명 언어(WSDL)와 XML 기반 인터페이스 설명 언어 설명 웹 서비스가 제공하는 기능.

단순 대상 접근 프로토콜(SOAP)은 XML 기반 메시지 전달 프로토콜로 컴퓨터 간에 구조화된 정보를 교환하는 데 사용된다.

Representational State Transfer(REST)는 소프트웨어 구조 스타일로 유니버설 네트워크의 디자인과 개발을 지도하는 데 쓰인다.

gRPC 원격 프로세스 호출(gRPC)은 구글이 2015년 개발한 오픈소스 원격 프로세스 호출이다.

GraphQL은 API의 소스 데이터 조회와 조작 언어이자 기존 데이터를 사용하여 조회를 실행할 때이다.

자바스크립트 대상 표현법(JSON)은 개방된 표준 파일 형식과 데이터 교환으로 인간이 읽을 수 있는 텍스트를 사용하여 데이터를 저장하고 전송한다.

네트워크 서비스
웹 서비스는 다른 응용 프로그램과 상호작용할 수 있도록 HTTP 인터페이스를 공개하는 것으로 광범위하게 정의할 수 있다.그러나 더 엄격한 정의는 웹 서비스는 WSDL, SOAP, XML만 공개할 수 있다는 것이다.이러한 정의는 REST, GraphQL, GRPC 등 다른 종류의 인터페이스를 포함하지 않기 때문에 보통 유행이 지났다.
간단하게 말하면 웹 서비스는 기계가 각종 네트워크와 서버를 이용하여 서로 통신하는 방식의 하나다.웹 서비스는 다른 컴퓨터로부터의 요청을 감청하고 요청을 받을 때 JSON, XML, HTML 파일을 사용하여 필요한 정보를 보내는 웹 서버를 포함한다.
웹 서비스가 인터넷을 사용해야 한다는 사실은 웹 서비스와 API 간의 본질적인 차이이다.
일반적으로 모든 웹 서비스는 API이지만 모든 API가 웹 서비스는 아니다.
웹 서비스는 소규모 내부 업무 라인 응용 프로그램에서 대형 공공 웹 API까지 규모와 범위의 차이가 매우 크다.아마존 네트워크 서비스(AWS), Azure, 곡가운은 일부 가장 큰 공공 네트워크 서비스 제공 업체이다.그들의 인터넷 서비스는 anomaly detection와language translation부터 동영상transcoding까지 무엇이든 할 수 있다.
더 좋은 것은 클라우드 공급업체가 웹 서비스를 제공할 뿐만 아니라 인프라 시설도 제공하여 가상 머신(VM), 서버 기능과 용기를 포함하여 다양한 방식으로 웹 서비스를 실행할 수 있도록 도와준다.

API
API는 여러 소프트웨어 어플리케이션 또는 혼합 하드웨어 소프트웨어 메커니즘 간의 상호 작용을 정의하는 인터페이스입니다.API는 기본적으로 개발자나 다른 응용 프로그램에 사용할 수 있도록 응용 프로그램이나 라이브러리를 사용하는 모든 방법을 가리킨다.이 인터페이스들은 웹 서비스의 형식을 채택할 수 있지만, 반드시 그렇지는 않다.
웹 서비스와 API 사이의 관건적인 차이점은 오프라인과 로컬에서 API를 사용할 수 있고 웹 서비스를 온라인으로 사용해야 한다는 것이다.네트워크를 통해 직접 연결하는 대신 동일한 시스템에서 API를 사용할 수 있으므로 일부 API는 네트워크를 사용하지 않고도 상호 작용할 수 있습니다.
일반적으로 개발자가 하나의 API를 언급할 때 그들은 보통 인터넷을 통해 접근할 수 있는 웹 API를 가리키는데 웹 서비스와 매우 비슷하다.앞에서 말한 바와 같이 다른 응용 프로그램은 같은 컴퓨터에서 Unix 플러그인, 공유 파일 접근, 메시지 대기열을 사용하여 API를 공개할 수 있지만 웹 서비스의 경우 영원히 그렇지 않을 것이다.
로컬 API의 한 예는 Windows 시스템에서 사용되는 어셈블리 개체 모델(COM)입니다.COM은 마이크로소프트가 1993년에 최초로 내놓은 소프트웨어 구성 요소 2진 인터페이스 표준이다.itdocumentation에서 COM에 대한 자세한 내용을 확인할 수 있습니다.

REST API 아키텍처의 예
다음은 웹 서비스이자 API인 REST API의 예를 살펴보겠습니다.
컴퓨터 과학자 로이 필딩은 2000년 박사 논문Architectural Styles and the Design of Network-based Software Architectures에서 REST 건축 스타일을 정의했다.REST는 웹 서비스와 API가 어떻게 서로 상호작용하여 효율적이고 접근성을 유지하는지에 대한 제약을 정의합니다.REST는 도입 이후 개발자에게 웹 서비스와 API 구축 방식을 안내해 왔다.
우리는 REST의 제약에 복종하는 모든 웹 서비스가 RESTful이라고 생각할 수 있다.REST 호출은 웹 서비스와 API를 동시에 사용하는 시스템의 좋은 예이다. 웹 서비스이기 때문에 인터넷에서 실행되지만, 우리는 같은 기계의 두 응용 프로그램 사이에서 로컬로 사용할 수 있다.
REST 요청은 두 개의 필수 구성 요소와 세 개의 옵션 구성 요소로 구성됩니다.필요한 구성 요소는 다음과 같습니다.

URL 경로 [http://example.com/api]

HTTP 방법 [GET, PUT, POST, PATCH, DELETE]

옵션 구성 요소는 다음과 같습니다.

클라이언트가 서버에 전달해야 할 추가 정보를 포함하는 헤더

변수 필드의 매개 변수를 제공합니다. 이 변수 필드는 클라이언트가 받을 응답을 바꾸고 정의합니다

서비스를 제공할 때 서버에 전달해야 하는 모든 추가 정보의 주체

재미있는 예를 들어 다중 게임Rocket League에 관심이 있다고 가정해 보세요.Octane.gg는 로켓 프로 리그 데이터를 잘 방문하는 사이트다.Octane API를 호출하고 플레이어에 대한 데이터를 요청합니다.
우리의 REST 통화 구조는 다음과 같습니다.
HTTP 메서드:가져오기
웹 주소: https://zsr.octane.gg/players
매개 변수: id=3dcf jstn
이번 통화는 아이디를 지정한 프로 선수에 대한 기본 정보를 제공했다.
개인 데이터베이스에 POST 호출을 할 수 없기 때문에 좀 복잡한 GET 호출을 보겠습니다.이번에 우리는 2019년 세계선수권대회 결승전의 경기 데이터를 제공할 것을 요구한다.
HTTP 메서드:가져오기
웹 주소: https://zsr.octane.gg/stats/teams/events
매개 변수: 통계 = 목표와 팀 = 23a0 nrg 전자 경기와 경기 = 6744 nrg 전자 경기와 팀 활력
만약 우리가 API 테스트기, 예를 들어 reqbin를 사용한다면 우리는 이 호출의 출력을 다음과 같이 볼 수 있다.

{  
    "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

옥탄가.gg는 JSON 형식으로 우리가 요구한 정보를 반송합니다.JSON은 2019년 12월 15일 NRG 전자 경기팀이 팀 활력팀을 4대3으로 꺾은 것을 쉽게 이해할 수 있다.
이러한 호출은 개발자가 응용 프로그램에서 사용하도록 대량의 정보를 제공했다.대부분의 API 구조는 REST API 형식과 매우 비슷합니다(완전히 같지 않은 경우).
이런 연속성은 개발자가 인터넷에서 웹 서비스와 상호작용하는 데 뚜렷하고 간결한 방식을 제공했다.개발자로서 우리는 API와 웹 서비스를 사용하여 응용 프로그램의 능력을 강화하고 필요한 데이터를 제공할 수 있다.

결론
요컨대 웹 서비스와 API는 비슷한 목표를 달성했지만 근본적인 차이점도 있다.웹 서비스는 항상 온라인이며 네트워크가 있어야만 실행할 수 있다.네트워크를 통해 API를 요청할 수도 있지만 API를 만들어 로컬에서 사용할 수도 있어 동일한 시스템에서 애플리케이션이 서로 액세스할 수 있습니다.
또한 대부분의 웹 서비스에서 클라이언트의 API 호출을 포맷하는 데 사용되는 REST에 대해서도 논의했습니다.REST는 API 빌더 및 애플리케이션 개발자에게 원활한 아키텍처를 제공합니다.
웹 서비스와 API는 개발자가 오늘날 우리가 알고 좋아하는 인터넷을 만들 수 있도록 한다.때로는 보기 어려울 수도 있지만, 인터넷의 많은 부분은 웹 서비스와 API에 의존하여 대량의 응용 프로그램을 지원하는 데이터와 방법을 제공한다.
개발자로서 우리는 이 두 시스템이 제공하는 기능을 이용하여 그들의 차이를 이해하고 우리가 필요로 하는 제품을 만들어야 한다!
omponentOne]https://www.grapecity.com/componentone), 수상작.NET 및 JavaScript 디렉터, 많은 강력한 서버측 API가 제공됩니다!