Rest-API vs GraphQL-API
Rest API란
- API(Application Programming Interface)란
└ 데이터와 기능의 집합을 제공하여 컴퓨터 프로그램간 상호작용을 촉진하며, 서로 정보를 교환 가능 하도록 하는 것 - REST API의 정의
└ REST 기반으로 서비스 API를 구현한 것
└ 최근 OpenAPI, Micro Service 등을 제공하는 업체 대부분은 REST API를 제공함
REST API의 특징
- 사내 시스템들도 REST 기반으로 시스템을 분산해 확장성과 재사용성을 높여 유지보수 및 운용을 편리하게 할 수 있음
- REST는 HTTP 표준을 기반으로 구현하므로, HTTP를 지원하는 프로그램 언어로 클라이언트, 서버를 구현할 수 있음
- REST API를 제작하면 델파이 클라이언트 뿐 아니라, 자바, C#, 웹 등을 이용해 클라이언트를 제작할 수 있음
REST API 설계 기본 규칙
- URI는 정보의 자원을 표현해야 함
⑴ resource는 동사보다 명사를, 대문자보다는 소문자를 사용한다.
⑵ resource의 도큐먼트 이름으로는 단수 명사를 사용해야 한다.
⑶ resource의 컬렉션 이름으로는 복수 명사를 사용해야 한다.
⑷ resource의 스토어 이름으로는 복수 명사를 사용해야 한다.
└ Ex) GET /Member/1 → GET /members/1 - 자원에 대한 행위는 HTTP Method(GET, PUT, POST, DELETE 등)로 표현한다.
⑴ URI에 HTTP Method가 들어가면 안된다.
└ Ex) GET /members/delete/1 → DELETE /members/1
⑵ URI에 행위에 대한 동사 표현이 들어가면 안된다. (CRUD 기능을 나타내는 것은 URI에 사용하지 않는다.)
└ Ex) GET /members/show/1 → GET /members/1
└ Ex) GET /members/insert/2 → POST /members/2
⑶ 경로 부분 중 변하는 부분은 유일한 값으로 대체한다. (:id는 하나의 특정 resource를 나타내는 고유값이다.)
└ Ex) student를 생성하는 route: POST/students
└ Ex) id=12인 student를 삭제하는 route: DELETE /students/12
Rest API 설계 규칙
- 슬래시 구분자(/)는 계층 관계를 나타내는데 사용함
└ Ex) http://restapi.example.com/houses/apartments
- URI 마지막 문자로 슬래시(/)를 포함하지 않음
└ URI에 포함되는 모든 글자는 리소스의 유일한 식별자로 사용되어야 하며
URI가 다르다는 것은 리소스가 다르다는 것이고, 역으로 리소스가 다르면 URI도 달라져야 한다.
└ REST API는 분명한 URI를 만들어 통신을 해야 하기 때문에
혼동을 주지 않도록 URI 경로의 마지막에는 슬래시(/)를 사용하지 않는다.
└ Ex) http://restapi.example.com/houses/apartments/ (X)
- 하이픈(-)은 URI 가독성을 높이는데 사용
└ 불가피하게 긴 URI 경로를 사용하게 된다면 하이픈을 사용해 가독성을 높인다.
- 밑줄(_)은 URI에 사용하지 않음
└ 밑줄은 보기 어렵거나 밑줄 때문에 문자가 가려지기도 하므로 가독성을 위해 밑줄은 사용하지 않는다.
- URI 경로에는 소문자가 적합
└ URI 경로에 대문자 사용은 피하도록 한다.
└ RFC 3986(URI 문법 형식)은 URI 스키마와 호스트를 제외하고는 대소문자를 구별하도록 규정하기 때문
- 파일확장자는 URI에 포함하지 않음
└ REST API에서는 메시지 바디 내용의 포맷을 나타내기 위한 파일 확장자를 URI 안에 포함시키지 않는다.
└ Accept header를 사용한다.
└ Ex) http://restapi.example.com/members/soccer/345/photo.jpg (X)
└ Ex) GET / members/soccer/345/photo HTTP/1.1
Host: restapi.example.com
Accept: image/jpg (O)
- 리소스 간에는 연관 관계가 있는 경우
└ /리소스명/리소스 ID/관계가 있는 다른 리소스명
└ Ex) GET : /users/{userid}/devices (일반적으로 소유 'has'의 관계를 표현할 때)
REST API 설계 예시
CRUD | HTTP verbs | Route |
resource들의 목록을 표시 | GET | /resource |
resource 하나의 내용을 표시 | GET | /resource/:id |
resource를 생성 | POST | /resource |
resource를 수정 | PUT | /resource/:id |
resource를 삭제 | DELETE | /resource/:id |
응답상태코드
- 1xx : 전송 프로토콜 수준의 정보 교환
- 2xx : 클라이언트 요청이 성공적으로 수행됨
- 3xx : 클라이언트는 요청을 완료하기 위해 추가적인 행동을 취해야 함
- 4xx : 클라이언트의 잘못된 요청
- 5xx : 서버쪽 오류로 인한 상태코드
GraphQL-API란
- Facebook에서 만든 Graph Query Language(GQL)로 어플리케이션 레이어 쿼리 언어
- Structed Query Language(SQL)와 마찬가지로 쿼리 언어
└ SQL은 데이터베이스 시스템에 저장된 데이터를 효율적으로 가져오는 것이 목적
└ GQL은 웹 클라이언트가 데이터를 서버로부터 효율적으로 가져오는 것이 목적
└ SQL의 문장은 주로 백엔드 시스템에서 작성하고 호출함
└ GQL의 문장은 주로 클라이언트 시스템에서 작성하고 호출함 - API를 위한 쿼리 언어이고, 타입 시스템을 사용하여 쿼리를 실행하는 서버사이드 런타임
- 특정한 데이터베이스나 스토리지에 귀속되어 있지 않고, 기존 코드와 데이터에 의해 대체
- 서버사이드 GQL 어플리케이션은 GQL로 작성된 쿼리를 입력으로 받아 쿼리를 처리한 결과를 다시 클라이언트로 돌려줌
- HTTP API 자체가 특정 데이터베이스나 플랫폼에 종속적이지 않은 것처럼 마찬가지로 GQL 역시 어떠한 특정 데이터베이스나 플랫폼에 종속적이지 않음
SQL 쿼리 예시
GQL 쿼리 예시
GraphQL 특징
- REST API의 한계를 극복하고자 나왔음
- Endpoint는 통상 1개만 생성하고 클라이언트에게 필요한 데이터는 클라이언트가 직접 쿼리를 작성, 호출하여 반환 받음
GraphQL 예시
- 요청 쿼리
- 반환 데이터
GraphQL 장점
- 클라이언트가 필요한 데이터만 반환할 수 있음
- 1번의 호출로 원하는 데이터를 한번에 가져올 수 있음
- REST API의 N+1 Problem을 해결 할 수 있음
- 확장이 용이
GraphQL 단점
- 백엔드, 클라이언트 개발자 양쪽 다 러닝커브가 있음
- 단순한 서비스에서는 사용하기가 복잡함
- 캐싱 기능의 구현이 복잡함
- 요청이 text로 날아가기 때문에 File 전송 등을 구현하기가 어려움
'React > 2022-上' 카테고리의 다른 글
try ~ catch (0) | 2022.03.26 |
---|---|
Async / Await (0) | 2022.03.26 |
Template Literals (0) | 2022.03.24 |
Git (0) | 2022.03.23 |
Import & Export (0) | 2022.03.22 |