서문
이 작품은 AI를 사용하여 번역되었습니다. 여러분의 피드백과 의견을 환영합니다: translation-feedback@oreilly.com
수백만 명의 개발자가 사용하는 API로 인기 있는 개발자 플랫폼을 구축하는 것은 소프트웨어 커리어에서 가장 도전적이고 흥미로운 작업 중 하나입니다. 이 책에서는 그 방법을 배웁니다.
API는 최신 소프트웨어 개발의 핵심입니다. API는 소프트웨어 엔지니어로서 내가 작성한 코드를 다른 개발자가 함께 사용하고 혁신할 수 있도록 어떻게 노출할 수 있을까라는 기본적인 개발자의 과제를 해결해 줍니다. 현대 사회에서 소프트웨어를 구축하는 것은 레고 블록으로 조립하는 것과 매우 유사합니다. 개발자는 결제, 커뮤니케이션, 권한 부여 및 인증 등과 같은 서비스를 노출하는 방대한 API 세트에 액세스할 수 있습니다. 새로운 소프트웨어를 구축할 때 소프트웨어 엔지니어의 임무는 이러한 API를 사용하여 새로운 제품을 구성하고 다른 사람이 구축한 코드를 재사용함으로써 시간을 절약하고 같은 일을 반복하지 않도록 하는 것입니다.
어릴 적 레고 놀이를 즐겼던 많은 소프트웨어 엔지니어들은 지금도 레고 놀이를 좋아합니다. 안 좋아할 사람이 어디 있을까요? 재미도 있고, 서로 매끄럽게 연결되는 멋진 색상의 부품으로 유용한 물건을 만들 수 있으니까요. 하지만 레고 자체를 조립할 수 있다면 어떨까요? 새로운 레고 키트뿐만 아니라 레고 부품 자체를 발명하고 다른 사람들이 이를 통해 혁신을 이룰 수 있다면 정말 멋지지 않을까요? 자체 API를 구축하면 사실상 다른 개발자가 사용할 수 있는 레고 부품을 직접 만드는 것입니다.
API는 컴퓨터 과학에서 새로운 개념이 아닙니다. 60년대에 개발자들은 최초의 절차적 언어를 위한 표준 라이브러리를 구축하고 이를 다른 개발자들과 공유하기 시작했습니다. 이러한 개발자는 내부 코드를 몰라도 라이브러리의 표준 기능을 사용할 수 있었습니다.
그러다가 70년대와 80년대에 네트워크에 연결된 컴퓨터가 등장하면서 개발자가 원격 프로시저 호출(RPC)을 통해 사용할 수 있는 서비스를 노출하는 최초의 네트워크 API가 등장했습니다. RPC를 통해 개발자는 네트워크를 통해 자신의 기능을 노출하고 원격 라이브러리를 마치 로컬처럼 호출할 수 있었습니다. Java와 같은 프로그래밍 언어는 이러한 원격 서비스를 나열하고 오케스트레이션하는 메시징 미들웨어 서버를 통해 더욱 추상화되고 복잡해졌습니다.
90년대에 인터넷이 등장하면서 많은 회사들이 API를 구축하고 노출하는 방식을 표준화하고자 했습니다. CORBA(Common Object Request Broker Architecture), Microsoft의 COM(Component Object Model) 및 DCOM(Distributed Component Object Model) 등의 표준이 웹을 통해 서비스를 노출하는 사실상 표준이 되고자 했습니다. 문제는 이러한 표준 대부분이 관리하기 복잡하고, 네트워크 양쪽에서 유사한 프로그래밍 언어를 사용해야 하며, 원격 서비스의 일부(흔히 ...