Rest API, 순수 Javascript ajax 호출 방식 (XMLHttpRequest(), fetch())의 차이를 알아보자.

Rest API가 무엇인지는, 이 역시도 하나의 엄청나게 큰 주제이며 기술할 거리가 많다.

다만, 오늘 다룰 주제는 거기서 한차원 넘어간 Rest API를 실제로 사용하는 예제이기에

오늘 내 글에서 설명하는 개념은 약간의 진입장벽이 있다.

---

사전지식이 부족한 사람들을 위한 보충자료를 하나 남길까한다. 개인적으로는

Rest API, 개인적으로 정말 정리를 잘 했다고 생각되는 타 블로그의 글을 한개 인용하겠다.

REST API 제대로 알고 사용하기 : TOAST Meetup

이 부분은 코드를 가지고 실습을 한다기보다는 Rest API를 활용하여

서버 - 클라이언트 양자간 통신을 할 때, 필요한 재료와 각 재료의 성질을 알려주는 부분이다.

측, 요리를 할떄 각각의 재료와 구성된 재료 레시피의 원리를 설명하는 문서이다.

 

 

 

---

오늘 소개하는 것은, 레시피의 재료 구성이 끝난 직후 실제로 요리를 하는 법 즉 Ajax Call에 대해 다루고자 한다.

주 사용 언어는 제이쿼리 기반이 아닌, 자바스크립트이다.

인터넷에 검색해보면, Rest API를 다루는 방식의 대부분은 혼용 기술 되있거나 제이쿼리로 되있다.

아무래도 제이쿼리로 하는게 코드가 더 간단하다고 생각해서 그러는 모양이다.

 

개인적으로 제이쿼리는 매우 혐이라고 생각하는 언어이다. 왜냐 하면, 콘솔창에서 디버깅이 어렵기에 문제가 생기면 어디서 왜 생겼는지 파악 할 수가 없다. 소스코드 버전관리도 제대로 안되고, 이슈가 생기면 랜덤 트러블 슈팅 방식으로 일을 처리해서 급기야는 하드코딩을 남발하는 상황까지 벌어진다.

 

그래서 나는 제이 쿼리를 요리로 비교하면, 만들기만 쉬운 불량식품 레시피라고 하고 싶다.

 

Ajax콜은 어플리케이션의 동적인 통신기반 서비스이므로, 가장 많이 오류 발생하며, 보완할 이슈가 많이 발생한다.

서버사이드 코딩이 잘못된 경우도 있겠지만, CORS(도메인버그)도메인 버그, 함수 자체버그 등을 생각하면

JQuery는 그야말로 당신의 웹 소스를 망치는 암덩어리 시한 폭탄이 될것이다.

 

그러므로, 필자는 퓨어 자바 스크립트 기반의 Ajax Call을 추천한다. 물론, 기술 된 소스 자체만으로는 완벽하진 않다.

각 기능별로 함수 콜백 또는 promise로 설정한 약속등을 달아서  Rest API 재료 생성 - 함수 콜 - 비동기적 리턴 - 예외처리 및 동작 이 4박자에서 발생하는 예외상황들을 처리하려면 소스가 조금 더 복잡해질 수도 있다.

 

하지만, 집을 지을때도 그렇듯이 기반이 튼튼하면 충분히 보완할 수 있는 문제니까, 여기 사용한 소스에서 한발자국 더 나아가고 싶다면, 스스로 REST API의 URI 헤더 바디의 구조를 살피고 직접 개발자 도구를 키고 네트워크 처리결과를 확인하며 CORS, 콜백, Promise 알아 보는것이 가장 현명할 것으로 생각된다.

 

1) 가장 전통적인 XMLHttpRequest();

  let xhr = new XMLHttpRequest();
    xhr.onreadystatechange = function() {
        if (xhr.readyState === xhr.DONE) {
            if (xhr.status === 200 || xhr.status === 201) {
                console.log(xhr.responseText);
            } else {
                console.error(xhr.responseText);
            }
        }
    };
    xhr.open('GET', 'URL코드를 바꾸세요');
    xhr.send();

 

 

Ajax 시작하기

필자가 참고하고 짠 소스이다.

httpRequest.onreadystatechange = function(){
    // 서버의 응답에 따른 로직을 여기에 작성합니다.
};

httpRequest.open('GET', 'http://www.example.org/some.file', true);
httpRequest.send(null);

필자의 소스에 대해 이해하고 싶다면 아래의 두 파트를 일어보면 된다.

 

참고로 status 200의 경우 OK, 201의 경우(가급적 POST로 하는) Created에 해당한다. 

둘다 성공 사인이며, 범용성을 높이기 위해 추가했다.

여기까지가 일반적인 방법이다.

---

2) 신흥 강자 fetch()

XMLHttpRequest()로 Ajax Call을 구현하는 데는 큰 어려움은 없다.

그러나, 한가지 아쉬움이 있다면, 예외 처리 혹은 기능을 검증해서 보완을 하더라도,

난잡하게 소스를 중복해서 사용하게 되면 코드가 너무 길어져서 가독성이 떨어지며,

예외상황이 발생하는 구간들이 많아진다.

 

그래서 Promise방식으로 Status체크를 해서 리턴값을 확인하는 절차를 더 간결하게 하는 새로운 방식으로 보이는 fetch()라는 녀석이 나왔다.

 

fetch 값 안에 URL(정확히는 URI지만 헷갈림 방지), 메소드, body, 동기 비동기 등의 파라미터를 넣고

바로 실행하고 결과를 확인하는 매우 강력한 친구이다. 

 let result = fetch('URL코드를 바꾸세요', {
	method : 'get'
	})
    result.then(function(response) {
      console.log('response', response)
      console.log('header', response.headers.get('Content-Type'))
      return response.text()
    }).then(function(text) {
      console.log('got text', text)
    }).catch(function(ex) {
      console.log('failed', ex)
    });

 

Rest API 서버간 통신을 하는 AJax에서는 앞으로 fetch()를 앞으로 많이 권장될 것으로 보인다.

굳이 소스코드를 하나하나 파헤치지 않아도 충분한 가독성이 보이므로 해설은 생략하겠다.

 

단, 아직도 XMLHttprequest()이 친구가 더 많이 쓰이며 완전히 버리면 안되는 이유...

1) 가장 전통적인 방식이기 떄문에, 레거시 코드로 남아있다. (그냥 새로 넘어가자 라고 할 수도 없을 만큼 엄청 많다.)

2) 그 만큼 아직까지는 가장 안정적이고 검증된 방법이다.

3) fetch가 Promise기반의 새로운 기술이기 때문에 프로미스 녀석이 크롬 의존도가 높아서, 크로미윰 기반의 브라우저가 아닌 타 브라우저(대표적으로 만악의 근원인... 이제는 폐기물 처리 되기 직전인 Internet Explorer와 ActiveX)호환이 불가능하다.

 

약간의 TMI

제발, MS에서도 자기들 이미지 지키려면 차기 OS에서 아예 IE 자체를 서비스를 완전히 중단하고, 구글에 Window 지분 나눠주고 떳떳하게 크로뮴 기반인 엣지를 기본 브라우저로 출시했으면 좋겠다.

한편 JS의 Rest API의 호출방식은 이밖에도 JSP의 FORM(Spring 문법이라고 해야하나),  AJax를 활용하는 라이브러리 형태인 Axios 말고도 각 언어별로 다양한 문법이 있는 것으로 알고 있다. 다만 위에 소개한 방법들은 가장 범용으로 쓸 수 있는 방법이라고 판단 되어서 대표적으로 소개했다.