RestfulAPI , GraphQL
: Restfull API는 A가 어떤 방식으로 요청하고, B가 어떤 방식으로 응답할지 지정해 놓은 다양한 형식들 중 하나입니다.(1) Create : 정보를 생성해서 넣는 것(2) Read : 조회, 목록 또는 특정 정보를 조회하는 것 (3) Update: 정보를 업...
1. RESTful API
: RESTful API는 A가 어떤 방식으로 요청하고, B가 어떤 방식으로 응답할지 지정해 놓은 다양한 형식 중 하나입니다.
작업의 종류
(1) Create
: 정보를 생성해서 넣는 것
(2) Read
: 조회, 목록 또는 특정 정보를 조회하는 것
(3) Update
: 정보를 업데이트하는 것
(4) Delete
: 어떤 정보를 삭제하는 것
EX) URI 사용 예시
| POST | https://api.example.com/v1/infos | 새로운 정보 추가 |
|---|---|---|
| GET | https://api.example.com/v1/infos | 목록 받아오기 |
| GET | https://api.example.com/v1/infos/1 | 1인 정보 받아오기 |
| PUT | https://api.example.com/v1/infos/13 | 13인 정보 수정 |
| PATCH | https://api.example.com/v1/infos/10 | 10인 정보 변경 |
| DELETE | https://api.example.com/v1/info/50 | 50인 정보 삭제 |
=> HTTP는 RESTful API의 필수 요소는 아니지만, RESTful API의 조건을 구현하기 용이하기에 현업에서 HTTP가 주로 사용된다.

-
GET, DELETE
- 적은 양의 정보를 담을 수 있다.
- 쿼리 파라미터를 통해 정보를 구분하여 가져올 수 있다.
-
POST, PUT, PATCH
- 많은 양의 정보를 담을 수 있다.
- body라는 공간에 데이터를 실어 보낼 수 있다.
⇒ 각 메서드의 색상, 속성, URI를 통해 개발자들이 한눈에 봐도 알아볼 수 있다.
[
{
"id": 1,
"code": "WD0003",
"parentCode": "WITHDRAWAL",
"name": "제공된 정보가 기대에 미치지 못했어요",
"description": "제공된 정보가 기대에 미치지 못했어요",
"orderNumber": 0,
"tempVal1": "",
"tempVal2": "",
"tempVal3": ""
},
{
"id": 2,
"code": "WD0001",
"parentCode": "WITHDRAWAL",
"name": "필요한 정보를 다 얻었어요",
"description": "필요한 정보를 다 얻었어요",
"orderNumber": 0,
"tempVal1": "",
"tempVal2": "",
"tempVal3": ""
},
]
특징
-
RESTful API는 JSON 형태의 구조화된 데이터를 사용한다.
-
Stateless(상태가 없는) 통신
- 클라이언트의 상태 정보가 서버에 저장되지 않아야 한다.
- 클라이언트의 요청은 몇 번째 반복되든 필요한 모든 내용을 포함하고 있어야 한다.
-
Cacheability
- 응답을 캐싱해 두어서 가지고 있는 데이터를 DB에서 꺼내지 않고 보내줄 수 있다.
장점
-
직관적이어서 개발자 간 협업에 용이하다.
-
확장성이 좋다.
- 서버와 클라이언트 간 인터페이스가 명확하여 서로 간의 의존성이 낮다.
-
재사용성
- HTTP 프로토콜을 사용하기에 기존 웹 인프라를 그대로 이용 가능하다.
-
유지보수에 용이하다.
-
캐시 기능
- 서버 측 부하 분산에 좋다.
단점
- HTTP 프로토콜에 의존된다.
- URI 설계가 복잡할 수 있다.
- 상태 정보가 클라이언트와 서버 간에 전송될 수 있다.
2. GraphQL(질의를 하기 위한 언어)
: GraphQL은 애플리케이션 프로그래밍 인터페이스를 위한 쿼리 언어이자 서버 측 런타임으로, 클라이언트에게 요청한 만큼의 데이터를 제공하는 데 우선순위를 두며 API를 더욱 빠르고 유연하며 개발자 친화적으로 만들기 위해 설계되었다.
& 하나의 엔드포인트
: 일반적으로 POST를 사용하며, 하나의 엔드포인트를 사용한다.
(1) 데이터의 조회
: query

→ POST 메서드로 위와 같이 요청을 보낸다.
→ query에서 요청한 데이터만을, 즉 클라이언트가 필요로 하는 정보만 받아와서 REST API의 오버페칭을 방지할 수 있다.
→ 하나의 요청으로는 모든 데이터를 받아오지 못하는 언더페칭(underfetching) 문제가 발생하기도 한다.
(세부적으로 요청하기에 여러 요청이 필요한 경우가 생김)
(2) 데이터의 추가, 수정, 삭제
: mutation 사용
→ 좌측 사진과 같이 요청하면 우측의 데이터가 생성, 수정, 삭제된다.

(3) 구독(subscription)
: 구독을 신청하여 해당 데이터에 대한 변경 사항 알림을 받을 수 있다.
장점
- 하나의 엔드포인트로 한 번의 요청을 통해 여러 API의 정보를 가져올 수 있다.
- 필요한 데이터만 요청할 수 있다.
단점
-
캐싱이 어려움
- 요청들이 복잡하여 이를 기준으로 캐싱하기 어렵다.
-
서버 부담
- 복잡한 쿼리로 인해 서버에 부담이 될 수 있다.
참고
https://luvris2.tistory.com/530
https://www.redhat.com/ko/topics/api/what-is-graphql