Server API (혹은 Server-side web API)
는 적절한 요청을 하였을 때,
그에 맞는 응답을 되돌려주는 창구 (Endpoint) 를 Web 을 통해 노출한 것을 말한다.
이런 Server API 는 어떤 정보들(환율, 주식 시세, 뉴스 …)을 요청하고 수정하기 위해서 만들어지는 경우가 많다.
Server API 를 만드는 방법론 REST
와 GraphQL
이 있다.
📂
REST
HTTP URI를 통해 자원을 명시하고 , HTTP Method(post,get,put,delete)
를 통해 해당자원에 대한 CRUD Operation
을 적용하는 것을 의미한다.
REST API는 형식(주소) 만으로 대략 무슨 요청인지 알 게 해준다.
📂
RESTful
📂
RESTful API 이점
📝 확장성
REST API를 구현하는 시스템은 REST가 클라이언트-서버 상호 작용을 최적화하기 때문에 효율적으로 크기 조정할 수 있다.
무상태는 서버가 과거 클라이언트 요청 정보를 유지할 필요가 없기 때문에 서버 로드를 제거한다.
잘 관리된 캐싱은 일부 클라이언트-서버 상호 작용을 부분적으로 또는 완전히 제거한다.
이러한 모든 기능은 성능을 저하시키는 통신 병목 현상을 일으키지 않으면서 확장성을 지원한다.
📝 유연성
RESTful 웹 서비스는 완전한 클라이언트-서버 분리를 지원한다.
각 부분이 독립적으로 발전할 수 있도록 다양한 서버 구성 요소를 단순화하고 분리한다.
서버 애플리케이션의 플랫폼 또는 기술 변경은 클라이언트 애플리케이션에 영향을 주지 않는다.
애플리케이션 함수를 계층화하는 기능은 유연성을 더욱 향상시킨다. 예를 들어, 개발자는 애플리케이션 로직을 다시 작성하지 않고도 데이터베이스 계층을 변경할 수 있다.
📝 독립성
REST API는 사용되는 기술과 독립적이다.
API 설계에 영향을 주지 않고 다양한 프로그래밍 언어로 클라이언트 및 서버 애플리케이션을 모두 작성할 수 있다.
통신에 영향을 주지 않고 양쪽의 기본 기술을 변경할 수 있다.
📂
RESTful API 단점
📝 Restriction of HTTP Method
📝 Absence of Standard (표준의 부재)
GraphQL은 애플리케이션 프로그래밍 인터페이스(API)를 위한 쿼리 언어이자 서버측 런타임으로 클라이언트에게 요청한 만큼의 데이터를 제공하는 데 우선 순위를 둔다.
GraphQL은 API를 더욱 빠르고 유연하며 개발자 친화적으로 만들기 위해 설계되었다.
GraphQL은 API 유지 관리자에게 기존 쿼리에 영향을 미치지 않고 필드를 추가하거나 폐기할 수 있는 유연성을 부여한다. 개발자는 자신이 선호하는 방식으로 API를 빌드할 수 있으며, GraphQL 사양은 이러한 API가 예측 가능한 방식으로 작동하도록 보장한다.
📂
GraphQL API 이점
GraphQL 스키마는 GraphQL 애플리케이션에 신뢰할 수 있는 단일 소스를 하나 설정한다. 조직은 이를 통해 전체 API에 페더레이션할 수 있게 된다.
엄격하게 정의된 데이터 유형은 클라이언트와 서버 간 통신 오류를 줄여준다.
REST API로 사용할 수 없는 기능을 제공하기 위해 대부분의 오픈소스 GraphQL 확장 기능을 사용할 수 있다.
GraphQL은 특정 애플리케이션 아키텍처를 지정하지 않으므로 기존 REST API
에 추가하여 기존 API 관리 툴과 연동할 수 있다.
📂
GraphQL API 단점
REST API에 친숙한 개발자의 경우 GraphQL를 학습하는 데 시간이 필요하다.
GraphQL은 데이터 쿼리의 상당 작업을 서버측으로 옮겨 서버 개발자 작업의 복잡성이 커진다.
캐싱이 REST보다 훨씬 복잡하다.
API 유지관리자의 경우 유지 관리 가능한 GraphQL 스키마를 작성하기 위한 추가 태스크를 수행해야 한다.