웹 API 설계

2장. API 패러다임

이 작품은 AI를 사용하여 번역되었습니다. 여러분의 피드백과 의견을 환영합니다: [e-mail]

올바른 API 패러다임을 선택하는 것이 중요합니다. API 패러다임은 서비스의 백엔드 데이터를 다른 애플리케이션에 노출하는 인터페이스를 정의합니다. API를 처음 시작할 때 조직은 API를 성공적으로 만드는 모든 요소를 항상 고려하지는 않습니다. 그 결과 나중에 원하는 기능을 추가할 수 있는 충분한 공간을 확보하지 못합니다. 이는 시간이 지남에 따라 조직이나 제품이 변화하는 경우에도 발생할 수 있습니다. 안타깝게도 개발자가 API를 사용하고 나면 불가능하지는 않더라도 API를 변경하기가 어렵습니다. 시간과 노력, 골칫거리를 절약하고 새롭고 흥미로운 기능을 위한 공간을 확보하려면 시작하기 전에 프로토콜, 패턴 및 몇 가지 모범 사례를 생각해 보는 것이 좋습니다. 이렇게 하면 나중에 원하는 대로 변경할 수 있는 API를 설계하는 데 도움이 됩니다.

수년에 걸쳐 여러 API 패러다임이 등장했습니다. REST, RPC, GraphQL, WebHook, WebSocket은 오늘날 가장 널리 사용되는 표준 중 일부입니다. 이 장에서는 이러한 다양한 패러다임에 대해 자세히 살펴봅니다.

요청-응답 API

요청-응답 API는 일반적으로 HTTP 기반 웹 서버를 통해 인터페이스를 노출합니다. API는 일련의 엔드포인트를 정의합니다. 클라이언트는 해당 엔드포인트에 데이터를 HTTP로 요청하고 서버는 응답을 반환합니다. 응답은 일반적으로 JSON 또는 XML로 다시 전송됩니다. 서비스에서 요청-응답 API를 노출하기 위해 사용하는 세 가지 일반적인 패러다임이 있습니다: REST, RPC, GraphQL입니다. 다음 하위 섹션에서 각각에 대해 살펴보겠습니다.

대표 상태 전송

REST(Representational State Transfer)는 최근 API 개발에 가장 많이 사용되는 방식입니다. REST 패러다임은 Google, Stripe, Twitter, GitHub와 같은 제공업체에서 사용합니다. REST는 리소스에 관한 것입니다. 리소스는 웹에서 식별, 이름 지정, 주소 지정 또는 처리할 수 있는 엔티티입니다. REST API는 데이터를 리소스로 노출하고 표준 HTTP 메서드를 사용하여 이러한 리소스에 대한 CRUD(만들기, 읽기, 업데이트 및 삭제) 트랜잭션을 나타냅니다. 예를 들어 Stripe의 API는 고객, 요금, 잔액, 환불, 이벤트, 파일, 지급액을 리소스로 나타냅니다.

다음은 REST API가 따르는 몇 가지 일반적인 규칙입니다:

• 리소스는 /users 와 같은 URL의 일부입니다.

• 각 리소스에 대해 일반적으로 컬렉션용(예: /users)과 특정 요소용(예: /users/U123)의 두 가지 URL이 구현됩니다.

• 리소스에는 동사 대신 명사를 사용합니다. 예를 들어 /getUserInfo/U123 대신 /users/U123 을 사용합니다.

• GET, POST, UPDATE ...