API 설계방식 | REST, GraphQL, gRPC

API란 무엇인가?

• API는 Application Programming Interface의 약자야.
• 아주 간단히 말해서 "두 시스템(혹은 프로그램)이 서로 대화할 수 있게 하는 규칙"이라고 생각하면 돼.
• 컴퓨터 세계에서 "클라이언트"는 브라우저(크롬, 사파리)나 앱이고 "서버"는 데이터를 처리하고 저장하는 곳이야.
• "API"는 클라이언트와 서버 간의 약속된 규칙이야
  • 요청 규칙:
    클라이언트가 서버에 "이 데이터를 주세요!"라고 요청하려면 서버가 이해할 수 있는 형식으로 말해야 해.
    예) GET /users/123 → 서버에 "123번 유저 정보를 달라"는 요청.
  • 응답 규칙:
    서버는 요청을 받은 후 데이터를 처리해서 정해진 형식으로 클라이언트에 답을 줘.
    예) { "id": 123, "name": "Hyunji", "email": "hyunji@example.com" }

 

API 설계 방식 

API 설계 방식은 클라이언트와 서버가 대화하는 규칙을 어떻게 정할지를 다룬 거야.

"요청과 응답을 주고받는 구체적인 규칙"이라고 이해하면 돼.

 

REST, GraphQL, gRPC는 모두 API를 설계하고 구현하는 방법론 또는 통신 규칙이야.

이 세 가지는 클라이언트와 서버 간의 통신을 어떻게 구조화하고, 데이터를 주고받는 규칙을 정의할 것인지에 초점이 맞춰져 있어. 각각의 특징과 차이를 간단히 설명할게!

 

1. REST (Representational State Transfer)

• REST는 HTTP를 기반으로 클라이언트와 서버가 데이터를 교환하는 구조적인 방식이야. 주로 JSON 형식의 데이터를 주고받아.
• 특징:
  • 리소스 기반: URL이 특정 자원을 나타냄. 예: /users/123는 ID가 123인 사용자.
  • HTTP 메서드를 활용: GET, POST, PUT, DELETE 등을 사용.
  • 상태 비저장(Stateless): 서버는 요청 간에 클라이언트 상태를 유지하지 않아.
• 장점: 단순하고 직관적이며, HTTP의 기본 구조를 활용.
• 단점: 복잡한 요청이나 데이터 구조를 처리할 때 비효율적일 수 있음.

 

2. GraphQL

• Facebook에서 개발한 API 설계 방식으로, 클라이언트가 원하는 데이터만 요청하고 받을 수 있는 유연한 쿼리 언어야.
• 특징:
  • 클라이언트가 필요한 데이터를 명확히 지정. 예: query { user(id: 123) { name, email } } → 이름과 이메일만 반환.
  • 하나의 요청으로 여러 리소스에 접근 가능.
  • 데이터를 계층적으로 정의하고 요청.
• 장점: 데이터 전송량이 줄어들고, 클라이언트가 필요한 데이터만 가져올 수 있어.
• 단점: 복잡한 초기 설정과 학습 곡선이 있음.

 

3. gRPC (Google Remote Procedure Call)

• Google에서 만든 고성능 원격 프로시저 호출(Remote Procedure Call) 프레임워크로, 서버와 클라이언트 간의 통신을 위한 프로토콜이야.
• 특징:
  • 프로토콜 버퍼(Protobuf)라는 이진 형식을 사용해 JSON보다 데이터가 더 작고 처리 속도가 빠름.
  • 양방향 스트리밍 지원: 클라이언트와 서버가 동시에 데이터를 주고받을 수 있음.
  • 다중 언어 지원: 다양한 언어로 작성된 서버와 클라이언트 간의 통신 가능.
• 장점: 빠르고 효율적이며, 스트리밍 데이터 처리에 적합.
• 단점: REST나 GraphQL보다 설정이 복잡하고 디버깅이 어려움.

 

비교

	REST	GraphQL	gRPC
데이터 형식	JSON, XML	JSON	Protobuf (이진 데이터)
요청 방식	HTTP 메서드 기반	쿼리 언어	메서드 호출
효율성	데이터 오버페치/언더페치 가능	필요한 데이터만 요청 가능	고성능, 작은 데이터 크기
스트리밍 지원	제한적	제한적	지원
학습 곡선	쉬움	중간	어려움

 

요약

• REST: 가장 전통적이고 널리 사용되는 API 설계 방식.
• GraphQL: 클라이언트가 필요한 데이터만 가져오도록 설계된 유연한 API.
• gRPC: 고성능과 스트리밍이 필요한 서비스에 적합한 API.

네가 어떤 상황에서 어떤 API를 선택할지에 따라 이들의 강점과 약점이 달라질 거야! 

 

---

참고 : RESTful ?

• REST는 Representational State Transfer의 약자고, 자원(resource)을 HTTP를 통해 표현하는 방식이야.
• RESTful은 이런 REST의 원칙을 잘 따르는 구체적인 구현 방법을 말해.
• 즉, RESTful한 방식으로 API를 설계한다는 건 REST의 규칙에 맞게 API를 설계한다는 의미야.

 

RESTful의 주요 원칙:

1. 자원 중심: 모든 것이 자원(Resource)으로 취급돼. 예를 들어, users라는 자원을 다룬다면 /users라는 URI로 접근해.
2. HTTP 메서드 사용:
   • GET: 자원을 조회할 때 사용
   • POST: 자원을 생성할 때 사용
   • PUT: 자원을 업데이트할 때 사용
   • DELETE: 자원을 삭제할 때 사용
3. 상태 없는 통신: 각 요청은 독립적이어야 하고, 서버는 요청 간의 상태를 기억하지 않아야 해.
4. 표현: 자원은 JSON, XML 등의 형식으로 표현될 수 있어.

 

즉, RESTful한 방식은 REST API의 설계 원칙을 따르는 방식인 거지!

예를 들어, 어떤 서비스에서 사용자 정보를 처리하는 API가 있다고 할 때, RESTful한 방식이라면:

• GET /users → 사용자 목록 조회
• GET /users/{id} → 특정 사용자 조회
• POST /users → 새로운 사용자 생성
• PUT /users/{id} → 사용자 정보 수정
• DELETE /users/{id} → 사용자 삭제

 

이런 식으로 자원에 대한 CRUD 작업을 RESTful하게 설계하는 거야.

결국 RESTful API는 이런 규칙을 따르는 API이고, RESTful한 방식은 그런 규칙을 잘 적용한 설계 방식이라는 것!