[웹 개발 기초] 웹이란? & 웹 API

• 사용자가 웹페이지(ex 구글)를 볼 수 있는 이유
• 웹브라우저-서버가 보내는 응답을 받아 해석해줬기 때문
• JS 코드를 작성 → 앱브라우저에서 실행 → 서버에 요청을 보내는 것도 가능 (개발자도구 사용)
• request(요청), response(응답)서버에 response가 온 후에 then이 실행됨(콜백함수)
• then메소드는 fetch함수가 리턴하는 어떤 객체의 메소드 (=콜백을 등록해주는 메소드)
• fetch(’주소’) .then((response) ⇒ response.text()) .then((result) ⇒ { console.log(reslt); });
• 웹이란?
• 거미줄처럼 연결된 가상의 연결망 세계
• URL
  • 호스트(Host)
  • 전 세계 서버 중 하나의 서버를 특정
  • 경로(Path)
  서버에 있는 데이터 중 원하는 데이터를 특정 : 이 부분을 잘 설계하는 게 개발자의 역할
  • 쿼리(Query)
  • 존재할 수도, 하지 않을 수도 있음. 데이터에 관한 세부적인 요구사항(물음표 뒤 문자열)
• 웹에 존재하는 특정 데이터를 나타내는 문자열
• https (HyperText Transfer Protocol)
  • 스킴(Scheme)
  • 프로토콜의 이름. 프로토콜이란 통신을 하는 두 주체가 지켜야 하는 통신 규약
  • https의 ‘s’는 secure(안전한 http)의 줄임말

---

 

웹 API 배우기

• Web API란?
  • 개발할 때 사용할 수 있도록 특정 라이브러리나 플랫폼 등이 제공하는 데이터나 함수 등
  • 어느 URL로 어떤 리퀘스트를 보냈을 때, 무슨 처리가 수행되고, 어떤 리스폰스가 오는지에 관해 미리 정해진 규격
  • 백엔드 개발자와 프론트엔드 개발자가 모여 논의를 하고, 위와 같은 내용을 정리한 뒤 개발을 시작하게 됨(=설계)

 

• 데이터 포맷으로서의 json 데이터 / stringify와 parse 메소드를 갖고 있는 JSON 객체

 

• json 데이터 포맷 (Java Script Object Notation)
  • response에는 html(화면을 그리는 재료) 외에도 순수한 정보가 들어있는 종류도 있다(=json)
  • 자바스크립트로부터 비롯된 데이터 포맷이지만, 이 탄생 목적은 언어나 환경에 종속되지 않고, 언제 어디서나 사용할 수 있는 데이터 포맷이 되는 것이었다.
  • 대괄호, 중괄호, 프로퍼티의 이름(반드시 큰따옴표로 감싸야 함), 값
  • undefined, NaN, Infinity 등은 json의 값으로 사용할 수 없다
  • 주석을 포함할 수 없다

 

• JSON 사용법
  • JSON.parse(...) → string 타입의 json 객체를 javascript 배열로 변환할 수 있음
  • JSON.stringify(...) → json 객체를 body에 담아서 웹으로 전송하려면 string 타입으로 변환해주어야 함

 

• request의 종류
  • 어떤 쿼리를 요구하느냐에 따라 4가지 종류로 나뉨(CRUD)
    1. 데이터 조회(get메소드 - read데이터처리)
    2. 데이터 추가(post메소드 - create데이터처리)
    3. 데이터 수정(put메소드 - update데이터처리)
    4. 데이터 삭제(delete메소드 - delete데이터처리)
    • patch (put과 마찬가지로 수정할 때 사용하는 메소드이지만, put은 아예 새로운 데이터로 덮어쓰는 수정 / patch는 기존데이터의 일부만 수정)
    • head (get과 마찬가지로 정보를 받을 때 사용하는 메소드이지만, body는 제외하고 딱 head 부분만 받는다는 차이가 있음. 예를 들어 영상 파일을 받는 상황 등에서는 헤드만 받아서 용량을 조사해볼 수 있음)
  • 하나의 request는 head(정보를 담는 부분)와 body(실제 데이터를 담는 부분)로 나뉘어있다
  • 데이터를 추가하는 post나 수정하는 put에는 body가 필요하지만, 데이터를 조회하는 get이나 삭제하는 delete의 경우에는 body가 필요하지 않은 경우가 많다

 

• REST API란?
  • 개발자들이 web API를 설계할 때 준수하기 위해 노력하는 일종의 가이드라인
  • REST architecture가 되기 위한 6가지 조건
    • 1. Client-Server : 클라이언트와 서버 양측의 관심사를 분리해야 함
    • 2. Stateless : 클라이언트가 보낸 각 리퀘스트에 관해 서버는 어떠한 context도 저장하지 않는다. 즉, 매 리퀘스트는 각각 독립적인 것으로 취급된다는 뜻. 따라서 리퀘스트에는 항상 필요한 모든 정보가 담겨야 함. (* 이거 무슨 말인지 잘 모르겠는데...)
    • 3. Cache : 캐시를 활용해 네트워크 비용을 절감해야 함
    • 4. Uniform Interface
      • 4-1. 클라이언트와 서버는 리소스를 직접적으로 다루는 게 아니라, 리소스의 표현을 다뤄야 함 (ex 같은 자료에 대해 html파일을 받을 수도, png 파일을 받을 수도 있다) 이것도 무슨 말인지 모르겠는데...
      • 4-2. 서버의 리스폰스에는 현재상태 → 다른상태로 이전할 수 있는 링크를 포함해야 한다
      • 4-3. 클라이언트의 리퀘스트, 서버의 리스폰스는 둘 다 그 자체에 있는 정보만으로 모든 것을 해석할 수 있어야 한다.
      • 4-4. 리소스를 URI(Uniform Resource Identifier)로 식별할 수 있어야 함 (URI는 URL의 상위개념으로, 일단은 그냥 URL이라고 이해해도 큰 무리는 없음)
    • 5. Layered System : 클라이언트와 서버 사이에는 프록시, 게이트웨이 등의 중간 매개 요소를 두고 보안, 로드밸런싱 등을 수행할 수 있어야 함. 이를 통해 클/서 사이에 계층형 층(hierarchical layers)들이 형성됨
    • 6. Code-On-Demand : 클라이언트는 받아서 바로 실행할 수 있는 applet, script 파일을 서버로부터 받을 수 있어야 한다. (6번은 옵셔널한 조건임)

 

• response의 head에 들어있는 정보
  • 상태코드(status code)
    • 200 : 리퀘스트를 서버가 정상처리함
    • 404 : 해당 URL에 해당하는 데이터를 찾을 수 없음
    • 100번대 : 서버가 클라이언트에게 정보성 응답을 줄 때 (ex 업로드 해도 되겠니? 그래!)
    • 300번대 : 클라이언트의 리퀘스트가 아직 처리되지 않았고, 처리를 원하면 클라이언트 측의 추가작업 필요함
    • 400 : 리퀘스트 내부 내용의 문법에 오류 존재 등
    • 401 : 신원이 확인되지 않는 사용자로부터 온 리퀘스트를 처리할 수 없음
    • 403 : 신원은 확인되었지만 접근 권한이 없는 사용자라서 처리할 수 없음
    • 500번대 : 서버 측의 문제로 리퀘스트를 정상 처리할 수 없음

 

• multipart/form-data
  • 실무에서 중요
  • 여러 종류의 데이터를 하나로 합친 데이터를 의미하는 타입
  • 예시) 이미지, 텍스트, 영상이 포함된 게시글을 적고 업로드 버튼을 누를 때

 

• Ajax
  • 현재 페이지를 그대로 유지한 채로 서버에 리퀘스트를 보내고, 리스폰스를 받아서 새로운 페이지를 로드하지 않고도 변화를 줄 수 있도록 하는 기술
  • 자바스크립트를 사용하여 비동기적으로(=사용자의 현재화면에 영향을 미치지 않고) 작업할 수 있도록 하는 기술들의 집합
  • 예시) 구글맵에서 ‘명동성당’을 클릭했을 때 화면 새로고침을 안하고도 정보 팝업이 뜬다
  • 반대 예시) <a href=”...” /> 는 Ajax 통신이 아님
  • 자바스크립트에서는 XMLHttpRequest를 통해 Ajax 통신이 가능
  • 하지만 XMLHttpRequest 직접 사용은 예전 방식임
    • 이유1. 요즘에는 fetch함수를 사용해서 Ajax통신을 할 수 있음
    • 이유2. axios 패키지를 통해 XMLHttpRequest를 더 편하게 쓸 수 있음