웹브라우저 동작방식
면접 질문
👄💬 transform 속성을 사용하면 레이아웃 계산이 다시 수행되지 않아서 성능을 향상시킬 수 있습니다. 레이아웃 계산은 브라우저가 요소의 위치와 크기를 다시 계산하는 과정으로 비용이 많이 들기 때문입니다.
2. 애니메이션에서 display: none → display: block에 부드러운 동작이 적용되지 않는 이유를 설명해 주세요.
- display 속성은 요소의 렌더링 방식을 변경하는 것이며, display: none으로 설정하면 해당 요소가 화면에서 사라지고 레이아웃에도 영향을 주지 X (아예 사라짐) 따라서 요소가 display: none 상태에서 display: block으로 바로 변경되면 레이아웃이 한번에 업데이트되어 부드럽게 보이지 X
- display 값을 변경할 때는 요소가 순간적으로 나타나거나 사라지기 때문에 부드러운 전환 효과를 적용하기 어렵다.
👄💬 display로 값을 변경하는 것은 요소의 렌더링 방식을 변경하는 것입니다. 레이아웃이 한번에 업데이트가 되어 요소의 크기와 공간도 변화가 생겨서 부드러운 동작이 적용되지 않습니다.
++) 애니메이션은 기존 CSS 스타일을 다른 CSS 스타일로 부드럽게 전환하는 역할을 합니다.
이때 display: none 상태의 태그는 meta 태그와 같이 CRP (Critical Rendering Path)의 Render Tree 생성 단계에서 노드로 생성되지 않기 때문에 애니메이션에서 기존 CSS 스타일을 찾을 수 없어 부드러운 동작이 적용되지 않습니다.
+ 요소가 사라지는 부드러운 전환 효과를 적용하려면?
- opacity나 visibility와 같은 속성을 사용하는 것이 좋다.
- display: none은 요소를 화면에서 완전히 숨기고 공간도 차지하지 않게 되지만,opacity나 visibility와 같은 속성을 사용해서 요소를 사라지게 하면 요소는 화면에서 사라지지만, 요소의 크기와 레이아웃 공간은 유지되기 때문에 해당 요소의 공간은 다른 요소와 겹칠 수 있고 부드러운 애니메이션 효과를 적용할 수 있다.
3. 웹 브라우저의 렌더링 과정에 대해 설명하세요.
(1. 브라우저가 URL을 해석하고 웹 서버에 요청을 보낸다.)
2. 브라우저의 렌더링 엔진은 HTML 문서를 파싱해서 DOM트리 생성 + 스타일 요소를 파싱에서 CSSOM 트리 생성 => 두 트리를 결합해서 Render tree 생성
3. Layout 단계 => 각 노드의 위치와 크기 계산해서 레이어를 만든다.
4. painting 단계
5. composite 단계 : 생성된 레이어를 합성해 실제 화면에 나타냄
👄💬 브라우저의 렌더링 엔진은 HTML 문서를 파싱해서 DOM 트리를 생성하고 스타일 요소를 파싱해 CSSOM 트리를 생성합니다. 두 트리를 결합해서 Render tree를 생성합니다. 각 노트의 위치와 크기를 계산해서 레이어를 만듦니다. paingting 단계를 거쳐서 생성된 레이어를 실제 화면에 나타냅니다.
파싱?
- 구문 분석
- 브라우저가 코드를 이해하고 사용할 수 있느 구조로 변환하는 것
리플로우와 리페인트에 대해 설명하세요.
- 웹 인터렉션(움직임이 있거나 유저와 상호 작용을 할 수 있는 화면 및 액션)으로 렌더링 과정의 레이아웃을 반복해 수행하는 것을 리플로우라고 합니다. 페인트 과정을 반복해 수행하는 것을 리페인트라고 합니다.
https://velog.io/@jeju_daun/%EB%B8%8C%EB%9D%BC%EC%9A%B0%EC%A0%80-%EB%B8%8C%EB%9D%BC%EC%9A%B0%EC%A0%80-%EB%A0%8C%EB%8D%94%EB%A7%81-%EB%B0%A9%EC%8B%9D
4. 브라우저가 웹 페이지를 로드하는 과정에 대해 설명하세요
- 웹 브라우저에 URL 입력
- 웹 브라우저가 도메인의 IP 주소를 조회한다.(먼저 캐시를 찾고 DNS 검색)
- 웹 브라우저가 찾은 IP 주소를 기반으로 서버와의 TCP 연결을 시작함
- 웹 브라우저가 HTTP 요청을 서버로 전송 (필요 시, HTTPS 보안 통신이 진행됨)
- 웹 서버가 요청을 처리하고 응답을 다시 웹 브라우저로 전송함
- 웹 브라우저가 전송 받은 콘텐츠를 렌더링
https://aws.amazon.com/ko/blogs/korea/what-happens-when-you-type-a-url-into-your-browser/
👄💬 URL을 입력하면 웹 브라우저는 먼저 캐시를 찾고 DNS를 검색해서 IP 주소를 조회합니다. IP 주소를 기반으로 서버와 TCP 연결을 시작합니다. HTTP 요청을 서버로 전송하고 웹 서버는 응답합니다. 웹 브라우저는 전송 받은 콘텐츠를 렌더링합니다.
DNS (domain name system)
5. 클라이언트 사이드 렌더링(CSR)과 서버 사이드 렌더링(SSR)의 차이에 대해 설명해주세요.
렌더링?
-
서버로부터 받은 내용을 브라우저 화면에 표시하는 것
-
차이점 : 어디서 화면을 보일 페이지의 내용을 그리느냐의 차이
-
클라이언트 사이드 렌더링은 페이지의 내용을 브라우저에서 그리고 서버 사이드 렌더링은 서버에서 페이지의 내용을 다 그려서 브라우저로 던져줌
-
서버 사이드 렌더링(SSR)의 가장 큰 장점은 검색엔진 최적화(SEO) 가능, 단점은 페이지 요청마다 페이지 새로고침이 발생해서 서버 렌더링에 따른 부하가 발생.
-
클라이언트 사이드 렌더링(CSR) 장점은 필요한 부분만 리로딩 없이 서버로부터 받아서 화면을 갱신하게 된다. 단점은 초기 구동 속도가 느리고 검색엔진 최적화가 어려움 ex) React, Vue, Angular 등
검색 엔진 최적화(SEO)?
- 검색엔딘 결과 페이지에서 웹사이트 또는 웹사이트의 상위 노출도를 높이는 작업
- 검색엔진이 좋아하는 웹사이트의 조건을 갖추는 것
https://yozm.wishket.com/magazine/detail/1540/
👄💬 어디에서 화면에 보일 페이지 내용을 그리느냐의 차이가 있습니다.
SSR의 가장 큰 장점은 검색엔진 화적화가 가능하다는 것이고 단점은 페이지 요청마다 새로고침이 발생해서 서버 렌더링에 따른 부하가 발생한다는 것이다.
CSR의 장점은 필요한 부분만 리로딩 없이 서버로부터 받아서 화면을 갱신하게 됩니다. 단점은 초기의 구동 속도가 느리고 검색엔진 최적화가 어렵습니다.
HTTP Method
면접 질문
1. GET, POST 에대해 설명해주세요.
-
GET method는 클라이언트에서 서버로 어떠한 리소스로부터 정보를 요청하기 위해 사용되는 메서드, 데이터를 읽거나 검색할 때 사용되는 method
-
ex) 게시판의 게시물 조회
-
POST method는 리소스를 생성/업데이트하기 위해 서버에 데이터를 보내는 데 사용되는 메서드. GET과 달리 전송해야 될 데이터를 HTTP 메시지의 Body에 담아서 전송함
-
ex) 게시판에 게시글을 작성하는 작업 등을 할 때 사용됨
-
HTTP 메시지의 Body는 길이의 제한 없이 데이터를 전송 가능. 그래서 POST 요청은 GET과 달리 대용량 데이터를 전송할 수 있음
https://whales.tistory.com/120
쿼리 스트링이란?
- GET은 요청을 전송할 때, URL 주소 끝에 파라미터로 포함되어 전송되는 부분
- ex) www.example.com/show?name1=value1&name2=value2
- name1과 name2은 파라미터 명이고 value1과 value2는 파라미터의 값
GET 요청의 특징
- GET 요청은 캐시가 가능함
- 브라우저 히스토리에 남고 북마크 가능
- 길이 제한이 있다.
- 파라미터에 다 노출되어 중요한 정보를 다루면 안됨
- 데이터를 요청할 때만 사용됨
GET 요청의 특징
- 캐시되지 않고 브라우저 히스토리에 남지 않고 북마크 되지 X
- 데이터 길이에 제한 X
GET과 POST의 차이점 정리
- 사용목적 : GET은 서버의 리소스에 데이터를 요청할 때, POST는 서버의 리소스를 새로 생성하거나 업데이트할 때 사용
- 요청에 body 유무 : GET은 URL 파라미터에 요청하는 데이터를 담아 보내기 때문에 HTTP 메시지에 body가 X
- 멱등성 : GET 요청은 멱등이고, POST는 멱등이 X
멱등(Idempotent)이란?
- 연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질을 의미
- POST는 리소스를 새로 생성하거나 업데이트할 때 사용되기 때문에 멱등이 아니라고 볼 수 있다. 서버가 변경될 수 있다.
https://noahlogs.tistory.com/35
👄💬 GET은 서버에 리소스에 데이터 요청 시, POST는 서버의 리소스를 새로 생성하거나 업데이트할 때 사용합니다. GET은 URL 파라미터에 요청하는 데이터를 담아 보내고 POST는 요청하는 데이터를 HTTP 메시지의 Body에 담아서 전송합니다. 그리고 GET은 연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질인 멱등성이 있다고 할 수 있습니다.
2. 왜 GET요청은 요청하는 URL에 붙어서 전송될까요? (POST는 URL에 붙지 않잖아요!!)
- GET 요청이 URL에 정보를 붙여서 전송되는 이유는 HTTP 프로토콜의 설계 및 목적과 관련이 있다.
- 간결함 : 간단하고 명확한 방식으로 요청하는 정보를 전달 가능하다.
- 캐싱 및 브라우저 히스토리 : 캐싱에 이점을 제공, 브라우저 히스토리에 GET 요청을 저장하여 사용자가 이전 페이지로 이동하거나 북마크를 만들 수 있다.
- 북마크 가능 : 사용자는 특정 페이지 또는 리소스에 대한 링크를 북마크하거나 다른 사람에게 공유하기 쉬움
- RESTful 디자인 : RESTful 웹 서비스 디자인에서는 URL 경로와 퀴리 문자열을 활용함. 이렇게 하면 클라이언트와 서버 간의 상태를 효과적으로 관리하고 리소스 검색 가능
HTTP(Hypertext Transfer Protocol)
- 웹 서버와 클라이언트 간에 데이터를 주고받기 위한 프로토콜로, 웹 브라우저와 웹 서버 간의 통신을 처리하는 데 사용됨
3. 서버에서 POST, PUT, PATCH 요청을 받으면 각 메서드마다 리소스를 어떻게 다루나요?
- POST : 요청 데이터 처리, 주로 등록에 사용
- PUT : 리소스를 대체, 해당 리소스가 없으면 생성
- PATCH : 리소스 부분 변경
4. HTTP Method 중 OPTIONS 메서드는 언제 사용하나요?
- HTTP OPTIONS 메서드는 주어진 URL 또는 서버에 대해 허용된 통신 옵션을 요청
- 웹 개발을 하다 보면 네트워크 요청시 실제 원하는 요청(GET, PUT, POST, DELETE 등)전에 OPTIONS 요청이 발생하는 것을 볼 수 있다고 한다. 응답값을 확인하면 아무것도 없다.
- preflight라고도 불리는 OPTIONS 요청은 브라우저가 서버에게 지원하는 옵션들을 미리 요청하고 허가된 요청에 한해서 전송하기 위한 보안상의 목적이 있다.
- 발생하는 상황은 CORS와 관련이 있다.
CORS(Cross-Origin Resource Sharing)
현재 웹페이지가 웹페이지를 받은 서버와 다른 서버의 리소스를 요청하는 것을 의미
ex) 웹서버와 분리되어 있는 API 서버로 요청을 보내기, CDN의 이미지를 사용하는 것 등등
CDN(Content Delivery Network)
- 지리적 제약 없이 전 세계 사용자에게 빠르고 안전하게 콘텐츠를 전송할 수 있는 콘텐츠 전송 기술
- 서버와 사용자 사이의 물리적인 거리를 줄여 콘텐츠 로딩에 소요되는 시간을 최소화함
- CDN은 각 지역에 캐시 서버(PoP, Points of presence)를 분산 배치해, 근접한 사용자의 요청에 원본 서버가 아닌 캐시 서버가 콘텐츠를 전달한다.
OPTIONS 없이 요청을 보내는 경우
- GET, HEAD, POST 요청 중 하나
- user agent에 의해 자동으로 설정되는 (Connection, User-Agent, Fetch 스펙상 forbidden header로 정의되어 있는) 헤더 외에 CORS-safelisted request-header로 명시된 헤더들만 포함된 경우 (Accept, Accept-Language, Content-Language, Content-Type 등)
- Content-Type은 application/x-www-form-urlencoded, multipart/form-data, text/plain 중 하나
- 3가지 조건 중 하나라도 만족하지 않는 요청은 preflight 요청을 먼저 보냄
https://library.gabia.com/contents/infrahosting/8985/
https://nukeguys.github.io/dev/options-request/
https://jaeyeong951.medium.com/options-%EC%9A%94%EC%B2%AD%EC%9D%80-%EC%B2%98%EC%9D%8C-%EB%B3%B4%EB%8A%94%EB%8D%B0%EC%9A%94-sop-cors-398f780601bb
5. 조회 시 POST가 아닌 GET 방식을 사용하는 이유에 대해 자세히 설명하시오.
-
GET은 설계원칙에 따라 서버의 데이터나 상태를 변경시키지 않아야 Idempotent(멱등)하기 때문에 주로 조회를 할 때 사용됨
-
또 다른 이유는 웹페이지를 조회할 때, 원하는 페이지로 바로 이동하거나 이동시키기 위해서는 해당 링크 정보가 필요한데 POST의 경우에는 파라미터가 HTTP 패킷의 Body에 있기 때문에 링크 정보를 가져올 수 없음
-
GET은 URL에 파라미터를 가지고 있기 때문에 링크를 걸 때, 더 상세한 링크를 걸 수 있다.
-
POST는 게시글 생성, 삭제 등 서버의 상태나 데이터를 변경시킬 때 사용됨
-
URL 노출을 해야 다른 사용자들에게 URL을 공유할 때 내가 보던 화면을 그대로 보여줄 수 있는 게 좋을 수도 있다.
https://angelplayer.tistory.com/182
https://helloworld-88.tistory.com/39
++) ‘조회’라는 행위는 원본 리소스를 참고하는 기능입니다. 그렇기 때문에 원본 리소스에 대해서 변경하는 행위가 있으면 안되고 오직 ReadOnly의 기능을 취해야 합니다. 그렇기 때문에 멱등적이고 안전한 GET 요청이 멱등적이지 않고 원본 리소스를 변경할 수 도 있는 POST 요청에 비해 조회에 더 잘 맞는 기능이라고 할 수 있습니다. 추가적으로 GET 요청은 URL에 정보를 담아서 전송하기 때문에 브라우저 캐시를 저장할 수 있고, URL 공유에 유리합니다. (팀원 답변)
6. HTTP 메소드의 속성에 대해 설명해주세요.
- HTTP 통신은 Server와 Client간의 통신하는 방법 중 하나로 Client의 요청이 있을 때만 Server가 응답하여 처리하고 이후에는 연결을 끊는 방식이다.
- GET : 데이터 조회
- POST : 다양한 요청 처리
- PUT : 데이터 추가 또는 덮어쓰기
- PATCH : 데이터 수정
- DELETE : 데이터 삭제
안전한 메소드와 멱등한 것의 차이
- 안전한 메소드 => 서버의 상태를 변경X
- 멱등 => 서버 상태 변경 가능, 불러오는 값은 항상 같음
HTTP/HTTPS
면접 질문
1. public Key와 private Key 그리고 Symmetric Key가 브라우저와 서버에서 작동하는 방식에 대해 서술해주세요.
- 브라우저가 서버에 요청을 보내면, 서버는 브라우저에 자신의 공개 키를 전송합니다.
- 브라우저는 자신의 대칭 키를 전달받은 서버의 공개 키로 암호화합니다.
- 이렇게 암호화한 대칭 키를 다시 서버로 전달하면, 서버는 자신의 개인 키로 암호화된 키를 복호화하여 대칭 키를 얻어냅니다.
- 이렇게 서버가 대칭 키를 얻어내면 브라우저와 서버는 서로 갖고 있는 대칭 키로 안전하게 통신이 가능하게 됩니다.
2. HTTPS는 어떤 프로토콜인지와 사용하는 이유를 말해주세요.
- Hypertext Transfer Protocol Secure의 약자
- HTTP 프로토콜의 문제점은 서버에서부터 브라우저로 전송되는 정보가 암호화되지 않는 문제가 있는데 HTTPS 프로토콜은 SSL(보안 소켓 계층)을 사용함으로써 이 문제를 해결함
SSL(보안 소켓 계층)
- 서버와 브라우저 사이에 안전하게 암호화된 연결을 만들 수 있게 도와주고, 서버 브라우저가 민감한 정보를 주고받을 때 이것이 도난당하는 것을 막아줌
https://yozm.wishket.com/magazine/detail/130/
3. HTTP와 HTTPS의 차이점은 무엇인가요?
- 두 프로토콜 사이에 가장 커다란 차이점은 바로 SSL 인증서(사용자로부터 제공받은 데이터를 암호화한다.) 이다.
- HTTPS는 HTTP 프로토콜에 보안 기능을 추가한 것이라고 말할 수 있다.
- 그 외에도 HTTPS는 TLS(전송 계층 보안) 프로토콜을 통해서도 보안을 유지함
TLS(전송 계층 보안)
- TLS는 데이터 무결성을 제공하기 때문에 데이터가 전송 중에 수정되거나 손상되는 것을 방지하고, 사용자가 자신이 의도하는 웹사이트와 통신하고 있음을 입증하는 인증 기능도 제공함
4. HTTPS와 SSL Handshake에 대해 설명하세요.
- SSL Handshake은 HTTPS 연결을 설정할 때 사용되는 과정 중 하나로, 클라이언트와 서버 간에 데이터를 안전하게 교환하기 위한 암호화 키 및 인증을 설정하는 단계입니다.
- 클라이언트가 서버에 연결 요청을 보냅니다.
- 서버는 공개키와 디지털 인증서를 클라이언트에게 제공합니다.
- 클라이언트는 서버의 디지털 인증서를 확인하고, 서버의 공개키를 사용하여 세션 키를 생성합니다.
- 클라이언트는 이 세션 키를 서버의 공개키로 암호화하여 서버에게 전송합니다.
- 서버는 자신의 개인키를 사용하여 세션 키를 해독합니다.
- 이제 클라이언트와 서버 간에는 안전한 연결이 설정되고, 이를 통해 데이터는 암호화되어 전송됩니다.
5. HTTPS의 SEO 효과에 대해 설명해주세요.
- 검색 엔진 최적화 (SEO)
- 구글에서는 https화(SSL화)를 하고 있는지를 검색 순위의 결정 요소에 포함한다고 발표하고 있다. 2018.07부터 Chrome은 SSL 인증서가 없는 웹사이트는 “안전하지 않은 웹사이트”로 표시하고 있다.
- 검색엔진 뿐만 아니라 사이트 이용자들의 신뢰도 얻을 수 없다.
https://itconquest.tistory.com/entry/HTTPS%EC%99%80-SEO%EC%9D%98-%EA%B4%80%EA%B3%84-SSL%EC%9D%B4-%EA%B2%80%EC%83%89%EA%B2%B0%EA%B3%BC%EC%97%90-%EC%A3%BC%EB%8A%94-%EC%98%81%ED%96%A5
RESTful
면접 질문
1. Put과 Post의 차이점은 무엇일까요?
- POST는 새 리소스를 생성, PUT은 리소스를 수정 혹은 생성하는 역할을 한다.
- POST는 요청 시 마다, 새로운 리소스가 생성된다.
- PUT은 요청 시 마다, 같은 리소스를 반환한다.
- PUT은 멱등하다고 말할 수 있고, POST는 멱등하지 않다고 말할 수 있다.
PATCH와 PUT의 차이는?
- PATCH는 수정만 담당하며 리소스의 일부분만 수정할 때 사용, PUT은 리소스의 모든 속성을 수정하기 위해 사용함
2. RESTful한 API란?
RESTful API는 두 컴퓨터 시스템이 인터넷을 통해 정보를 안전하게 교환하기 위해 사용하는 인터페이스이다.
RESTful
- 일반적으로 REST라는 아키텍처를 구현하는 웹 서비스를 나타내기 위해 사용되는 용어
- REST 원리를 따르는 시스템은 RESTful이란 용어로 지칭됨
- RESTful API는 두 컴퓨터 시스템이 인터넷을 통해 정보를 안전하게 교환하기 위해 사용하는 인터페이스이다.
REST 원리가 뭔데? REST 아키텍처?
- REST는 Representational State Transfer의 약자로 자원을 이름(자원의 표현)으로 구분하여 해당 자원의 상태(정보)를 주고 받는 모든 것을 의미
- HTTP URI(Uniform Resourse Identifier)를 통해 자원을 명시하고, HTTP Method를 통해 자원에 대한 CRUD Operation을 적용하는 것을 의미
RESTful 목적
- 자원을 URI로 표현 -> 각 자원은 고유한 URI를 가지며, 이를 통해 자원을 고유하게 식별 가능
- HTTP 기반으로 하므로, 널리 사용되는 프로토콜 활용, 클라이언트와 서버 간의 통신을 단순화한다.
- 자원을 표현하고 다루는 데 표준화된 방법을 제공하고, 확장성을 향상시키며, 상호 운용성 지원
- 확장성 향상 -> URI로 리소스 접근한다. URI는 계층적인 구조를 가질 수 있으므로 리소스를 효과적으로 구성하고 확장하기 용이함, HTTP 메서드(GET, POST, PUT, DEETE)를 사용해서 리소스 CRUD 작업을 수행하므로, 새로운 기능을 추가하거나 변경하기 비교적 쉬움.
- 상호 운용성 지원 -> 다양한 플랫폼과 언어에서 RESTful 서비스를 구현하고 사용하기 쉬움, 통신은 HTTP 요청과 응답을 사용해서 서로 다른 시스템 강에 데이터를 공유하고 통신하는데 문제가 발생하지 않는다. 일반적으로 사용하는 데이터 포맷 (JSON, XML)은 다양한 프로그래밍 언어와 플랫폼에서 해석하기 쉬운 형식
3. RESTful API 설계규칙에 대해 아는대로 말하시오.
- 웹 서비스를 설계하고 개발하는 데 사용되는 아키텍처 스타일 중 하나로 자원을 URI로 표현하고 HTTP 메서드를 사용해서 이러한 자원을 조작하는 방식을 기반으로 함.
- URI는 정보의 자원을 표현해야 함
- HTTP Method(GET, PUT, POST, DELETE 등) 적절히 사용
- URI 경로에 대소문자 구분 피하기 -> 호환성
- 리소스 간의 관계 표현하고 URI에 반영
- 사용자에게 의미 있는 상태 코드 반환 ex) 200 OK, 201 created, 404 Not Found
- 요청과 응답 형식 지정
- 버전 관리 고려
- 보안 고려
- 에러 처리 구현
- 문서화 유지하고 업데이트하기
https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html
4. RESTful API에서 리소스를 표현하기 위한 규칙인 URI 네이밍 규칙을 3개 이상 말해주세요.
- 리소스의 명사적인 표현 사용 ex) /users -> URI가 직관적이고 예측 가능하게 함
- 복수 개체를 나타내는 경우, 복수형 사용
- 슬래시로 하위 리소스 나타내기
- HTTP 동작 동사 사용 - URI가 간결하고 직관적으로 유지됨
- URI 내에서 단어 구분 시, 하이픈 또는 밑줄 사용
- 특정 리소스를 식별하기 위한 ID가 필요한 경우, 해당 ID를 URI에 포함시키기
5. AJAX와 REST의 차이를 설명해주세요.
- AJAX는 클라이언트 측에서 비동기적으로 데이터를 가져오고 업데이트하는 기술(데이터 통신 기술)로 주로 웹 페이지에서 사용된다. 데이터 형식에 제약이 없으며, XML, JSON, HTML 등 다양한 형식 사용 가능.
- REST는 웹 서비스의 아키텍처 스타일로, 클라이언트와 서버 간의 통신 방식을 정의한다. RESTful 웹 서비스는 주로 API를 구축할 때 사용된다. 주로 JSON을 사용하여 데이터를 전달하며, 자원을 나타내는 URL 구조를 따른다.
+) 6. Axios와 fetch의 차이
axios
- 브라우저, Node.js를 위한 Promise API를 활용하는 HTTP 비동기 통신 라이브러리
fetch
axios와 fetch는 모두 웹 애플리케이션에서 데이터를 가져오기 위한 JS 라이브러리 및 API이다.
1. 브라우저 지원
axios는 브라우저와 Node.js에서 모두 사용 가능하지만 fetch는 브라우저에서만 기본 제공된다.
2. API 사용법
axios는 프로미스 기반 API로 비동기 처리하기 더 쉬움. fetch는 프로미스를 반환하지만 설정 및 오류 처리에 더 많은 작업이 필요하다.
3. 브라우저 호환성
axios는 다양한 브라우저에서 안정적으로 동작하며, 브라우저 호환성을 더 잘 지원.
fetch는 오래된 브라우저에서 호환성 문제 발생 가능하다.
4. 인터셉터
axios는 인터셉터를 통해 요청과 응답 가로채고 수정 가능하고 fetch는 기본적으로 인터셉터를 제공하지 않음.
인터셉터
- 특정 URI로 요청 시, Controller로 가는 요청을 가로채는 역할을 한다.