<Web> RestAPI & GraphQL

RestAPI

REST API(Representational State Transfer API)는 웹 서비스의 아키텍처 스타일 중 하나로, HTTP 프로토콜을 사용하여 클라이언트와 서버 간의 통신을 수행합니다. REST는 리소스를 중심으로 설계되며, 각 리소스는 고유한 URI(Uniform Resource Identifier)로 식별됩니다. 클라이언트는 HTTP 메서드(GET, POST, PUT, DELETE 등)를 사용하여 서버에서 리소스를 조회하거나 조작할 수 있습니다.

 

동작 원리

1. 클라이언트 요청: 클라이언트는 특정 리소스에 대해 HTTP 요청을 보냅니다. 예를 들어, GET 메서드를 사용하여 리소스를 조회할 수 있습니다.
2. 서버 처리: 서버는 요청을 받아 해당 리소스를 처리하고 적절한 응답을 생성합니다.
3. 응답 반환: 서버는 처리 결과를 HTTP 응답으로 클라이언트에 반환합니다. 이 응답에는 상태 코드와 함께 요청된 리소스의 데이터가 포함됩니다.

장점

• 단순성 : HTTP 프로토콜을 기반으로 하여 쉽게 이해하고 사용할 수 있습니다.
• 캐시 가능 : HTTP의 캐시 메커니즘을 활용할 수 있어 응답 시간을 줄일 수 있습니다.
• 독립성 : 클라이언트와 서버가 독립적으로 개발될 수 있어 유연성과 확장성이 높습니다.
• 표준화 : URI, HTTP 메서드, 상태 코드 등의 표준을 사용하여 일관된 인터페이스를 제공합니다.

단점

• 과다한 데이터 전송 : 불필요한 데이터가 전송될 수 있어 네트워크 자원을 비효율적으로 사용할 수 있습니다.
• 복잡한 쿼리 : 복잡한 데이터 구조를 조회할 때 여러 번의 요청이 필요할 수 있습니다.
• 버전 관리 : API의 변경 사항을 관리하기 위해 버전 관리를 해야 할 필요가 있습니다.

---

 

REST API : Method + URI라는 2가지 요소로 구성 → RESTful API는 REST 철학을 적용한 방식

• Method = 동사 - 어떤 행위(Method)를 할 것인지
• URI(URL) = 명사 (목적어) - 어떤 자원(Resource)에 대해
  • URL, Location : https://abc.com = 장소
  • URI, Indicator : https://abc.com/users/cholsu/favorite-things = 장소 내 지정
  • URI 구성 : /collection/document(id)/store/ - 총 4 요소

• Collection - Document의 상위 디렉터리 리소스 (예, People)
• Document - Collection 내 단일 리소스 (예, Person)
• Store - Document 특정 형태 - 하위 리소스, 리소스의 다른 표현 (예, Person’s Favorites)
• Controller - 표현가능 Method(CRUD) 제외한 행위 명시 - 필요에 따라 URI 마지막에 표현
  • 예) /people/12/register - 12번 Person에 대한 회원등록 (POST 표현 강화)
• URI (Path)에 들어가는 변수
  • Path Variable : /hello/world
  • Query Parameter : /hello**?next=world**

---

GraphQL

GraphQL은 페이스북에서 개발한 쿼리 언어로, 클라이언트가 요청한 데이터의 형태를 지정할 수 있게 해주는 API 기술입니다. 클라이언트는 필요한 데이터만 요청할 수 있으며, 서버는 하나의 엔드포인트에서 모든 요청을 처리합니다.

 

동작 원리

1. 클라이언트 쿼리: 클라이언트는 필요한 데이터 필드를 명시한 쿼리를 서버에 보냅니다.
2. 서버 처리: 서버는 클라이언트 쿼리를 해석하여 데이터베이스 또는 다른 소스로부터 데이터를 조회합니다.
3. 응답 반환: 서버는 요청된 데이터를 JSON 형식으로 클라이언트에 반환합니다.

장점

• 유연성 : 클라이언트는 필요한 데이터만 정확히 요청할 수 있어 데이터 전송이 효율적입니다.
• 단일 엔드포인트 : 모든 요청이 단일 엔드포인트를 통해 처리되므로 API 관리가 용이합니다.
• 버전 관리 불필요 : 클라이언트가 요청하는 데이터 구조를 정의할 수 있어 API 버전 관리를 필요로 하지 않습니다.
• 강력한 개발자 도구 : 쿼리 작성과 테스트를 위한 다양한 도구와 에코시스템을 제공합니다.

단점

• 복잡성 증가 : 서버와 클라이언트 모두에서 GraphQL 스키마를 설계하고 관리해야 합니다.
• 오버헤드 : 모든 요청을 처리하는 단일 엔드포인트가 병목이 될 수 있으며, 복잡한 쿼리는 성능 저하를 초래할 수 있습니다.
• 캐싱 어려움 : HTTP 캐싱이 어렵기 때문에 별도의 캐싱 전략이 필요합니다.

---

REST API는 각 비즈니스 도메인마다 수많은 API 들을 일일이 만들어야 하는 단점이 있습니다.

• 예를 들어, 유저 도메인에 대한 단순 API 만든다 하더라도 GET, POST, DELETE, PUT, PATCH  → 5개
• 유저 도메인 + 결제 도메인 등 모두 합치게 된다면...
• 하나의 서비스를 위해 백엔드 서버가 제공해야 하는 API 수는 수십 수백 개

---

REST API vs GraphQL

차이점

• 데이터 요청 : REST는 고정된 엔드포인트와 여러 요청을 통해 데이터를 받는 반면, GraphQL은 단일 엔드포인트에서 필요한 데이터를 정확히 요청할 수 있습니다.
• 유연성 : GraphQL은 클라이언트가 필요한 데이터만 요청할 수 있어 네트워크 효율성이 높습니다. REST는 과다한 데이터를 전송할 수 있습니다.
• 버전 관리 : REST는 버전 관리가 필요하지만, GraphQL은 클라이언트가 데이터를 정의하기 때문에 버전 관리가 필요 없습니다.
• 복잡한 쿼리 처리 : REST는 복잡한 쿼리를 여러 번의 요청으로 처리해야 하는 반면, GraphQL은 단일 쿼리로 처리할 수 있습니다.

선택 기준

• 단순한 API : 간단한 CRUD 작업과 같은 단순한 API는 REST가 적합합니다. 표준화된 구조와 쉬운 구현이 장점입니다.
• 복잡한 데이터 요구사항 : 복잡한 데이터 요구사항과 동적 쿼리가 필요한 경우 GraphQL이 더 효율적입니다. 클라이언트가 필요한 데이터만 요청할 수 있어 네트워크 사용이 최적화됩니다.
• 빠른 개발과 변화 : 빠르게 변하는 요구사항이나 여러 클라이언트가 다양한 데이터 형식을 필요로 하는 경우 GraphQL이 더 적합합니다.
• 성능 최적화 : 고성능이 요구되거나 HTTP 캐싱이 중요한 경우 REST가 더 나을 수 있습니다. GraphQL의 단일 엔드포인트는 성능 병목이 될 수 있습니다.

결론적으로, REST와 GraphQL은 각각의 장점과 단점을 가지고 있으며, 특정 상황과 요구사항에 따라 적절한 방식을 선택하는 것이 중요합니다. REST는 간단하고 표준화된 방식으로, GraphQL은 유연하고 효율적인 데이터 요청을 가능하게 합니다.