본문 바로가기

Web/기초

[WEB기초] REST API vs GraphQL 차이점

GraphQL / RESTful

GraphQL

  • 서로 다른 모양의 다양한 요청들에 대해 응답할 수 있어야 할 떄
  • 대부분의 요청이 CRUD에 해당할 때
  •  

RESTful

  • HTTP, HTTPs에 의한 Cacheing을 잘 사용하고 싶을 때
  • File 전송 등 단순한 Text로 처리되지 않는 요청들이 있을 때
  • 요청의 구조가 정해져 있을 때

 

  • 아래 글 요약
    • REST에서는 Resource에 대한 형태 정의와 데이터 요청 방법이 연결되어 있지만, GraphQL에서는 Resource에 대한 형태 정의와 데이터 요청이 완전히 분리되어 있습니다.
    • REST에서는 Resource의 크기와 형태를 서버에서 결정하지만, GraphQL에서는 Resource에 대한 정보만 정의하고, 필요한 크기와 형태는 client단에서 요청 시 결정합니다.
    • REST에서는 URI가 Resource를 나타내고 Method가 작업의 유형을 나타내지만, GraphQL에서는 GraphQL Schema가 Resource를 나타내고 Query, Mutation 타입이 작업의 유형을 나타냅니다.
    • REST에서는 여러 Resource에 접근하고자 할 때 여러 번의 요청이 필요하지만, GraphQL에서는 한번의 요청에서 여러 Resource에 접근할 수 있습니다.
    • REST에서 각 요청은 해당 엔드포인트에 정의된 핸들링 함수를 호출하여 작업을 처리하지만, GraphQL에서는 요청 받은 각 필드에 대한 resolver를 호출하여 작업을 처리합니다.

 

 

Server API

  • Server API(Server-side web API)는 적절한 요청을 했을 때 그에 맞는 응답을 되돌려 주는 창구(Endpoint)를 Web을 통해 노출한 것입니다.
  • Server API는 어떤 정보들(회원, 시험, ...)을 요청하고 수정하기 위해서 만들어지는 경우가 많습니다.
  • 이 Server API를 만드는 방법론 중 하나로  REST라는 것이 있습니다.

 

REST와 RESTful (REpresentational State Transfer)

모든 Resource(자료, User, ...)들을 하나의 Endpoint에 연결해놓고, 각 Endpoint는 그 Resource와 관련된 내용만 관리하게 하는 방법론 입니다.

  • 자원(Recsource)의 표현(Representation)에 의한 상태 전달
    • REST API는 그 주소만으로 무슨 요청인지 알 수 있습니다.
  • HTTP URI를 통해 자원을 명시하고, HTTP Mehod(POST, GET, PUT, PETCH, DELETE)를 통해 해당 자원에 대한 CRUD(Create, Read, Update, Delete)를 적용하는 것

1. REST

- REST의 목표

  • 구성 요소 상호 작용의 규모 확장성
  • 인터페이스의 범용성
  • 구성 요소의 독립적인 배포

- REST 구성요소

  • 자원(Resource)
    • 해당 소프트웨어가 관리하는 모든것 입니다.
    • ex. DB의 유저정보를 표현하자면, member
  • 행위(Verb)
    • HTTP Method
  • 표현(Prepresentations)
    • 정보의 자원은 URI(Uniform REsource Identifier)로 표현됩니다.

 

- REST의 6가지 제약조건

1) Client - Server : Client, Server의 역할을 명학하게 구분해야 합니다.(서로 의존X)

2) Stateless : Client -> Server 하나의 요청에는 그 요청을 이해하는 데 필요한 모든 정보가 포함되어야 한다.(HTTP 특징)

3) Cache : 요청에 대한 응답 내의 데이터에 해당 요청은 캐시가 가능한지 불가능 한지 명시해야 한다.(HTTP Cacheable)

4) Uniform Interface : 약속된 interface를 사용해서 Client, Server 각각 독립적으로 진행할 수 있는 유연한 시스템이어야 한다.

5) Layered System : 각 구성들 간의 계층을 마음대로 상호작용 할 수 없도록 제한(Client는 REST 서버에 요청을 보낼 뿐, 직접 최종 서버에 요청을 한 것인지 중간 중개자에게 요청을 한지 알 수 없다. 원하는 결과를 받았는지 여부만 중요하다.)

6) Code On Demand( Optional ) : Client에 보내는 데이터를 바로 실행 가능한 코드(ex. Javascript)를 보내서 Client의 기능을 일시적으로 확장하거나 사용자 정의를 할 수 있따.

 

ex. REST의 조건을 만족하는 API

게시판 API = /board
글 작성 = POST /board
글 수정 = PSTCH /board/{board_id}
글 삭제 = DELETE /board/{board_id}

댓글 API = /board/{board_id}/comments
댓글 작성 = POST /board/{board_id}/comments
댓글 수정 = PATCH /board/{board_id}/comments/{comments_id}
댓글 삭제 = DELETE /board/{board_id}/comments/{comments_id}

 

2. RESTful

REST 제약조건을 준수한 웹 서비스 API를 말합니다.

  • 장점
    • HTTP 프로토콜을 사용하므로 별도 인프라를 구축할 필요가 없습니다.
    • URI만으로 의도하는 바를 쉽게 파악할 수 있습니다.
    • 서버와 클라이언트의 역할을 명확하게 분리합니다.
  • 단점
    • 표준이 존재하지 않습니다.
    • 사용할 수 있는 메소드가 제한됩니다.
    • 구형의 브라우저가 아직 지원하지 못합니다.

 

GraphQL(Graph Query Language)

Query Language : 정보를 얻기 위해 보내는 질의문(Query)을 만들기 위해 사용되는 언어입니다.

RESTful API로는 다양한 기종에서 필요한 정보들을 일일히 구현하는 것이 힘들어서 나오게 되었습니다.

ex. IOS, Android에서 필요한 정보들이 조금씩 다를 경우, 다른 부분마다 API를 신규로 작성합니다.

정보를 사용하는 측에서 원하는 대로 정보를 가져올 수 있고, 보다 편하게 정보를 수정할 수 있도록 하는 표준화된 Query Language를 만들게 되었습니다.

클라이언트에서 저장하고 호출합니다.

ex.

sql)
select * from exam
where
	no = '930202'
;

// 데이터 베이스에 보내는 질의어

graphql call)
query {
  exam(no:"930202") {
    no
    exam,
    reuslts{
    	selCd
        score
    }
  }
}

// Client 에서 Api 에 보내는 graphql 질의어


graphql return)
{
  "data": {
    "exam": {
      "no": "930202",
      "exam": "333,
      "reuslts": [
        {
          "selCd": "1000
          "score": "78
        },
        {
          "selCd": "2000
          "score": "67
        }
      ]
    }
  }
}

 

  • 장점
    • 하나의 Endpoint
    • HTTP 요청의 횟수를 줄일 수 있습니다.
      • RESTful은 각 Resource별로 요청
      • GraphQL은 원하는 정보를 하나의 Query에 모두 담아서 요청
    • HTTP 응답의 Size를 줄일 수 있습니다.
      • RESTful은 응답의 형태가 정해져있고, 필요한 정보만 부분적으로 요청하는 것이 힘듭니다.
      • GraphQL은 원하는 대로 정보를 요청하는 것이 가능합니다.
  • 단점
    • 하나의 Endpoint를 사용하기 때문에 HTTP에서 제공하는 캐싱 전략을 그대로 상용하는 것이 불가능합니다.
    • File 전송 등 Text만으로 하기 힘든 내용을 처리하기 복잡합니다.
    • 고정된 요청과 응답만 필요한 경우에는 Query로 인해 요청의 크기가 RESTful API보다 커집니다.
    • 재귀적인 Query가 불가능합니다.