44장: Rest API

• 2000년 로이 필딩이 논문에 처음 소개

  • -> 당시 웹이 HTTP를 제대로 활용하지 못하고 있었음
  • -> HTTP를 잘 활용할 수 있는 형태(구조)를 제공

• Rest: HTTP를 기반으로 클라이언트가 서버의 리소스에 접근하는 방식을 규정한 아키텍처(구조)

• 구성

  • 자원 -> URI
  • 행위 -> 메서드
  • 표현 -> 페이로드

• 설계 원칙

  • URI는 리소스 표현 -> 명사를 사용
  • 리소스에 대한 행위 -> GET, POST, PUT, PATCH, DELETE

45장: 프로미스

• 비동기 처리 단점
  • 콜백 패턴 -> 콜백 지옥
  • 에러 처리 곤란 -> 비동기 처리 결과 외부 반환X, 상위 스코프 변수 할당X

프로미스

• 비동기 처리 상태와 처리 결과를 관리하는 객체
• new Promise로 프로미스 객체 생성
• resolve, reject 인수를 받음
• 비동기 성공시 -> resolve 함수 실행 -> promise를 fulfilled 상태로 변경
• 비동기 실패시 -> reject 함수 실행 -> promisefmf rejected 상태로 변경
• 비동기 처리 결과도 가지고 있음
• 후속 처리 메서드 -> .then, .catch, .finally

프로미스 체이닝

• then, catch, finally 후속 처리 메서드는 언제나 promise를 반환 하기 때문에 후속 처리 메서드를 연속으로 쓸 수 있음
• 후속 처리 메서드의 콜백함수는 프로미스의 비동기 처리 상태가 변경되면 선택적으로 호출됨

프로미스 정적 메서드

• Promise.resolve/reject -> 값을 래핑하여 promise값 생성
• Promise.all -> 비동기 병렬처리 - 순서대로
• Promise.race -> 가장 먼저 fulfilled된 프로미스를 반환
• Promise.allSettled -> 모드 settled 상태가 되면 처리 결과를 배열로 반환

마이크로태스크 큐

• 프로미스 후속 처리 메서드는 마이크로태스크 큐에 임시 저장됨
• 다름 함수 혹은 이벤트 핸들러가 임시 저장되는 태스크 큐 보다 빠르게 처리됨(우선순위가 높음)

fetch

• HTTP 응답을 나타내는 response객체를 래핑한 promise 객체 반환
• 응답 body를 얻으려면 response.json()을 통해 얻을 수 있음
  • 응답 body를 얻어 역직렬화해서 반환
• fetch 에러 처리
  • 에러가 발생시 response.ok의 불리언 값을 false로 설정함
  • response.ok로 에러처리 해야함

46장: 제너레이터와 async/await

• 제너레이터: 코드 블록의 실행을 일시 중지했다가 다시 재개 할 수 있는 특수 함수
  • function* 로 정의
  • 함수 호출자에게 함수 실행 제어권 양도
  • 호출자와 함수 상태 주고 받음
  • 제너레이터 객체를 반환
    • 이터러블 & 이터레이터
      • 이터러블 -> Symbol.iterator 메서드 상속
      • 이터레이터 -> 이터레이터 리절트객체(value, done), next() 메서드

일시중지, 재개

• yield 키워드

  • 함수 실행 일시 중지
  • yield 뒤 표현식 결과를 제너레이터 함수 호출자에게 반환

• next() 메서드 실행 -> yield 표현식까지 실행하고 일시중지

  • 함수 제어권이 함수 호출자로 양도됨

• async/await

  • 동기처럼 프로미스 사용 가능
  • async
    • 언제나 프로미스 반환
    • await는 반드시 async 안에서만 사용
  • await
    • 프로미스가 settled가 될 때 까지 대기하고 resolve 처리 한 결과를 반환

47장: 에러 처리

• 에러 처리를 해야하는 이유

  • 발생한 에러에 의해 프로그램이 강제 종료된다.
    -> 예외적인 상황이 발생할 수 있다는 것을 전제하고 코드 작성해야함!

• 에러처리 방법

1. 예외적인 상황에서 반환값으로 if문 처리
2. 에러처리 코드 미리 등록

• try ... catch ... finally ...

• try문 실행, 에러 발생 -> catch(err) 에러 err을 받음 -> finally 에러 상관없이 무조건 한 번 실행

• Error 객체

  • const error = new Error('invalid')
  • message 프로퍼티 -> 생성자 함수에 인수로 전달한 메세지
  • stack 프로퍼치 -> 에러를 발생시킨 콜스택 호출 정보 문자열
  • 7개의 에러 객체가 존재함

• throw 문

  • 에러 객체를 던지는 용도 -> catch에서 그 에러를 받음

• 에러 전파

  • 에러는 호출자 방향으로 전파됨(실행 컨텍스트 위에서 밑으로)
    => 전역에서 캐치 가능하다!