개발자에 다가가기 위한 공부를 하면서 저에게 있어 가장 어려운 과정은 API를 만드는 과정이었습니다. 오늘은 그 API를 만들 수 있는 두 가지 방법에 대해 기록하려고 합니다.
우선 REST-API 먼저 이야기를 하겠습니다. 우선, REST는 나머지의 REST가 아니라, Representational State Transfer의 줄임말입니다. 한국말로 풀어서 설명하면, 자원(Resource)을 이름으로 구분하여 해당 자원의 상태를 주고받는 것을 의미합니다.
조금 더 자세한 표현을 찾고 싶었습니다.
REST API (RESTful API とも言います) は、REST アーキテクチャスタイルの制約に従い、RESTful Web サービスとの対話を可能にするアプリケーション・プログラミング・インタフェース (API または Web API) です。REST は REpresentational State Transfer の略で、コンピュータ・サイエンティストの Roy Fielding によって作られました。
REST API 는 RESTful API 라고 한다는 내용은 이번에 기록하면서 잘 알게되었습니다. 가끔은 한국어뿐만 아니라, 영어나 일본어로 정보를 찾아보고는 하는데, 도움이 되는 부분이 큰 것 같습니다. 그럼 개념을 알았으니, 특징을 파악해보려고 합니다.
REST-API의 특징은
-
계층형 구조 -> 말 그대로, 다중 계층으로 구성할 수 있습니다.
-
Client- Server 구조 -> 사용자 인증 및 내용들은 직접 매니징하는 구조기에, 유관부서간 의존성이 현저히 줄어든다는 특징이 있습니다.
-
Self-descriptiveness -> 쉽게 이해할 수 있는 특징이 있습니다.
-
Cacheable -> HTTP의 웹 표준을 그대로 차용해왔기에, 인터넷에서 구현할 수 있는 부분들을 그대로 활용 가능합니다.
-
Stateless -> 따로 상태에 대한 부분들을 관리하지 않습니다.
-
Uniform -> 한정적인 인터페이스로 일처리를 진행합니다.
이렇게 특징을 파악하고 나니, 장,단점에 대해서 알아야겠다고 생각했습니다.
장점은 위의 특징들에서도 파악할 수 있지만, 쉬운 사용법과 다양한 언어를 이용하여 작성할 수 있다는 점이 있습니다.
반면 단점은, STANDARD한 가이드가 존재하지 않고, 형태가 상당히 제한을 많이 받는다는 점입니다.
다음으로는 GRAPHQL-API 특징에 대해 알아보겠습니다. 처음 REST-API를 공부하고 나서 들었던 생각은, 왜 이름에 GRAPH가 붙었을까 입니다. 그에 대한 답은, 그래프조차도 구현이 가능하다였는데, 이 부분에 대해서는 계속 공부해 나가겠습니다. GRAPHQL-API 특징은 다음과 같습니다.
-
신속한 기능
REST API는 클라이언트의 까다로운 요구사항과 많은 피드백 속에, 서버에 정보를 노출 시킬 가능성이 높은 편입니다. 하지만, GRAPHQL-API는 상대적으로 이런 점에 있어서 우위에 있습니다. -
다양한 프레임워크
백엔드의 중요성도 부각되어감과 동시에, 프론트엔드에서도 각종 새로운 도구들로 무장한 툴들이 계속해서 출시되고 있습니다. GRAPHQL-API는 이러한 변화에 맞춰서 모두를 만족시킬 수 있는 API를 만들고 보수하는 것이 가능합니다. -
효율적인 퍼포먼스의 필요성
사실 1번의 특징과 어느정도 맥락을 같이 하는 부분인데, 웨어러블 장비와 같이 데이터를 주고 받는 일들이 현재에 빈번하게 일어나고 있는 요즘, 필요한 최소한의 정보만 별도로 요청이 가능한 특징상, 퍼포먼스의 효율성도 증대시킬 수 있습니다.
하지만, 마찬가지로 GRAPHQL-API라고 단점이 존재하지 않는건 아닙니다.
STANDARD한 구현 방법이 정해져 있지 않기에 업로드 방법은 항상 직접 해야하는 부분입니다.
또한, 고정된 요청과 응답을 요구하기때문에 오히려 REST보다 효율성이 떨어질 수도 있습니다.
이렇게 두 방법들을 공부하면서 느낀 점은, 사실, 기술은 계속해서 진보하고 신기술들은 나온다는 점입니다. 앞으로 학업을 게을리하지 않고 꼭 개발자가 되기 위한 걸음들을 지속적으로 내딛어야겠다고 이번 글을 기록하면서 다짐했습니다.
