-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
1 changed file
with
167 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,167 @@ | ||
# 📌 API 연동 방법 | ||
|
||
| ||
## CORS Error | ||
|
||
- **CORS란?** | ||
|
||
**Cross-Origin Resource Sharing로 교차 출처 리소스 공유이다.** | ||
|
||
교차 출처란 다른 출처라고 할 수 있다. | ||
|
||
즉, 다른 출처를 가진 리소스에 접근할 수 있게 하는 보안 메커니즘이다. | ||
|
||
- **출처(Origin)란?** | ||
|
||
![image](https://github.com/inu-appcenter/basic-study-16th/assets/62889359/c62b9ec6-d9ec-4d56-b634-0e58f51b984b) | ||
|
||
출처란 URL에서 Protocol, Port, Host를 의미한다. | ||
|
||
- **CORS Error란?** | ||
|
||
기본적으로 웹브라우저는 SOP(Same-Origin-Policy)라는 동일 출처 정책을 지킨다. | ||
|
||
즉, 동일 출처(Same-Origin) 서버에 있는 리소스는 자유롭게 가져올 수 있지만, 다른 출처(Cross-Origin) 서버에 있는 이미지나 유튜브 영상 같은 리소스는 상호작용이 불가능하다는 말이다. | ||
|
||
따라서 CORS Error는 SOP에 위배되는 리소스를 가져올 때 나타나는 에러이다. | ||
|
||
하지만 SOP Error가 아닌 CORS Error인 이유는 다른 Origin에 있는 리소스를 가져올 때, | ||
|
||
CORS 정책을 지키면 허용해주기 때문에 CORS 정책을 안지켰다는 에러이다. | ||
|
||
| ||
## Mocking | ||
|
||
- Mocking이란? | ||
|
||
Mocking은 프론트엔드에서 백엔드의 서비스를 모방하는 기술로, 실제 서버를 사용하지 않고 API 호출 프로세스를 모방하는 기술이다. | ||
|
||
- Mocking의 필요성 | ||
|
||
웹 개발 과정에서 백엔드 시스템이나 외부 API와의 통신이 필요한 경우가 많다. | ||
|
||
이때, 실제 서비스나 API가 준비되지 않았거나, 테스트를 위해 특정 응답을 조작해야 할 필요가 있을 때 모킹(Mocking)이 필요하다. | ||
|
||
모킹은 개발 초기 단계에서부터 백엔드와의 통신을 가정하고 프론트엔드 개발을 진행할 수 있게 해주며, 단위 테스트에서도 외부 의존성 없이 코드를 검증할 수 있게 해준다. | ||
|
||
- 구현 방법 | ||
|
||
이러한 모킹은 MSW(Mock Service Worker)와 같은 도구를 사용하여 구현할 수 있다. MSW는 서비스 워커를 활용해 네트워크 요청을 가로채고, 미리 정의된 응답을 반환함으로써 실제 백엔드 없이도 웹 애플리케이션을 테스트할 수 있게 해준다. | ||
|
||
| ||
## 각 HTTP Method마다 return해줘야하는 Status Code는? | ||
|
||
- 200 Ok | ||
|
||
클라이언트의 요청을 서버가 정상적으로 처리했다. | ||
|
||
성공에 대한 모든 상태 코드를 200으로 응답해도 크게 상관없다. | ||
|
||
하지만, 클라이언트에게 더 정확하고 자세한 정보를 제공하기 위해선 적절한 상태 코드를 보내는 것이 좋다. | ||
|
||
거의 모든 HTTP Method에 사용한다. | ||
|
||
- 201 Created | ||
|
||
클라이언트의 요청을 서버가 정상적으로 처리했고 새로운 리소스가 생겼다는 뜻이다. | ||
|
||
주로 POST, PUT 요청에 대한 응답으로 사용된다. | ||
|
||
- 204 No Content | ||
|
||
클라이언트의 요청은 정상적이다. 하지만 컨텐츠를 제공하지 않는다는 뜻이다. | ||
|
||
주로 DELETE 요청에 대한 응답으로 사용된다. | ||
|
||
자원 삭제 요청을 했고 이 요청이 유효하니 서버는 해당 자원을 삭제했다. 더 이상 응답할 컨텐츠가 없기 때문에 컨텐츠가 없는 204로 응답한다. | ||
|
||
| ||
## 4xx, 5xx Status code 중 사용할만한 Status Code 정리해보기 | ||
|
||
**4XX Client Errors: 클라이언트의 요청이 유효하지 않아 서버가 해당 요청을 수행하지 않았다.** | ||
|
||
- 400 Bad Request | ||
|
||
클라이언트의 요청이 유효하지 않아 더 이상 작업을 진행하지 못하는 경우이다. | ||
|
||
주로 유효성 검사 실패 시 사용한다. | ||
|
||
- 401 Unauthorized | ||
|
||
클라이언트가 인증이 되지 않았기에 자원을 이용할 수 없는 상태이다. | ||
|
||
주로 로그인같은 인증이 안된 상태일 때 사용한다. | ||
|
||
- 403 Forbidden | ||
|
||
클라이언트가 권한이 없기 때문에 작업을 진행할 수 없는 경우이다. | ||
|
||
주로 인증된 클라이언트가 권한이 없는 자원에 접근할 때 응답하는 상태 코드다. | ||
|
||
- 404 Not Found | ||
|
||
클라이언트가 요청한 자원이 존재하지 않다는 뜻이다. | ||
|
||
주로 경로가 존재하지 않거나, 자원이 존재하지 않을 때 사용한다. | ||
|
||
- 404 Conflict | ||
|
||
클라이언트의 요청이 서버의 상태와 충돌이 발생한 경우이다. | ||
|
||
주로 아이디같은 하나만 존재해야하는 리소스를 또 생성한다거나, 모순되는 상태일 때 사용한다. | ||
|
||
**5XX Server Errors: 서버 오류로 인해 요청을 수행할 수 없다.** | ||
|
||
클라이언트의 요청은 유효하여 작업을 진행했는데 도중에 오류가 발생한 경우다. | ||
|
||
API 서버의 응답에서 5XX오류가 발생해서는 안된다. | ||
|
||
주로 개발자의 실수로 인해 나타난다. | ||
|
||
| ||
# 📌 웹 브라우저에서 특정 페이지를 표시할 때까지 서버에 요청하고 받는 과정 | ||
|
||
1. 웹 브라우저에 URL을 입력한다. | ||
2. 웹 브라우저가 도메인의 IP주소를 조회한다 (먼저 캐시를 찾고, 그 다음 DNS를 검색한다.) | ||
3. 웹 브라우저가 찾은 IP주소를 기반으로 서버와의 TCP 연결을 시작한다. | ||
4. 웹 브라우저가 HTTP(S) 요청을 서버로 전송한다 | ||
5. 웹 서버가 요청을 처리하고 응답을 다시 웹 브라우저로 전송한다. | ||
6. 웹 브라우저가 전송 받은 컨텐츠를 렌더링한다. | ||
|
||
| ||
# 📌 캐시 | ||
|
||
## 캐시(Cache)의 의미 | ||
|
||
Cache란 자주 사용하는 데이터나 값을 미리 복사해 놓는 임시 장소를 가리킨다. | ||
|
||
| ||
## 캐시는 왜 사용할까? (캐시의 장점) | ||
|
||
캐시에 데이터를 미리 복사해 놓으면, 계산이나 접근 시간 없이 더 빠른 속도로 데이터를 접근 할 수 있다. | ||
|
||
반복적으로 동일한 결과를 돌려주는 경우(특정 이미지 or 썸네일) 사용하거나, 접근 시간에 비해 원래 데이터에 접근하는 시간이 오래 걸리는 경우나, 값을 다시 계산하는 시간을 절약하고자 하는 경우에 사용한다. | ||
|
||
## 캐시 교체 알고리즘의 종류 | ||
|
||
캐시가 사용하는 리소스의 양은 무한대가 아니라 제한적이기 때문에, 캐시는 제한된 리소스 내에서 데이터를 빠르게 저장하고 접근할 수 있어야 한다. | ||
|
||
그래서 "캐시 교체 알고리즘"으로 어떤 데이터를 버리고 어떤 데이터를 저장할지 결정한다. | ||
|
||
1. FIFO(First in First Out) - 가장 먼저 들어간 캐시를 교체 | ||
2. LRU(Least Recently Used) - 가장 오랫동안 사용되지 않은 캐시를 교체 | ||
3. LFU(Least Frequently Used) - 사용 횟수가 가장 적은 캐시를 교체 | ||
|
||
이 중에서 많은 운영체제가 사용하고 있는 알고리즘은 2번, LRU가 가장 좋은 캐시 교체 알고리즘으로 평가되고 있습니다 | ||
|
||
그 이유는 가장 오랫동안 사용하지 않았던 데이터라면, 앞으로도 사용할 확률이 적다고 판단하기 때문이다. | ||
|
||
| ||
## 로컬에 캐싱되는 경우는 개발자 도구에서 어떻게 표시되는 지 확인해보세요! | ||
|
||
1. **개발자 도구 열기:** 브라우저에서 웹 페이지를 로드한 후 F12 키를 눌러 개발자 도구를 연다. | ||
2. **네트워크 탭 선택:** 개발자 도구에서 네트워크 탭을 선택합니다. 이 탭은 웹 페이지가 요청한 자원들의 로딩 상태를 보여준다 | ||
3. **페이지 새로고침:** 웹 페이지를 새로고침하여 페이지에서 요청한 자원들을 로드한다. | ||
4. **캐시된 자원 확인:** 네트워크 탭에서 로드된 자원들의 목록을 확인할 수 있다. 캐시된 자원은 아래 그림처럼 “Served from memory cache”와 같은 문구가 뜬다. 이는 로컬 캐시에서 가져온 것임을 나타낸다. | ||
|
||
![image](https://github.com/inu-appcenter/basic-study-16th/assets/62889359/5253090d-0b1f-436e-861f-da894cf6ec52) |