비동기와 동기는 웹 개발에서 중요한 개념입니다.

이 두 방식은 웹 애플리케이션에서 데이터를 주고받는 방법을 설명하며, 각각 고유한 장단점이 있어 상황에 따라 적절하게 사용합니다.

1. Sync(동기)

 - 요청과 응답이 동시에 이루어지는 방식입니다. 웹 페이지를 새로고침하면서 데이터를 불러오는 경우가 이에 해당합니다. 예를 들어, 온라인 쇼핑몰에서 사용자가 결제 정보를 입력하고 결제 버튼을 누르면, 페이지가 새로고침되면서 결제가 처리되고, 새 페이지에 결제 완료 정보가 표시됩니다.

장점

1. 코드의 간결성
   - 동기 통신은 요청과 응답이 순차적으로 이루어지므로, 코드를 작성하고 이해하기 쉽습니다.
2. 순서 보장
   - 요청을 보낸 후 응답을 받아야 다음 작음을 수행할 수 있으므로, 요청과 응답의 순서가 보장됩니다.
3. 에러 처리 용이
   - 요청과 응답이 연결되어 있어, 에러 발생 시 처리하기 쉽습니다.

단점

1. 성능 저하
   - 페이지 전체를 새로고침해야 하므로 서버와의 통신량이 많아지고, 성능이 저하될 수 있습니다.
2. 사용자 경험 저하
   - 페이지가 깜빡거리거나 멈추는 형상이 발생하여, 사용자가 불편함을 느낄 수 있습니다.
3. 작업 차단
   요청을 보낸 후 응답을 기다려야 하므로, 다른 작업을 동시에 수행할 수 없습니다.

2. Async(비동기)

 - 요청과 응답이 동시에 이루어지지 않는 방식입니다. 페이지를 새로고침하지 않고, 필요한 부분만 업데이트하는 경우가 이에 해당합니다. 예를 들어, 실시간 채팅 애플리케이션에서 메세지를 전송하면, 전체 페이지를 새로고침하지 않고 채팅 창에만 새 메시지가 나타납니다.

장점

1. 성능 향상
   -  페이지의 일부만 업데이트하므로, 웹페이지의 속도와 성능이 향상됩니다.
2. 사용자 경험 개선
   - 화면이 깜박거리거나 멈추지 않고 부드럽게 작동하여, 사용자 경험이 향상됩니다.
3. 병렬 작업 가능
   - 요청을 보낸 후에도 다른 작업을 수행할 수 있습니다.

단점

1. 코드 복잡도 증가
   - 비동기 통신은 코드 작성과 이해가 어려울 수 있으며, 복잡도가 증가할 수 있습니다.
2. 순서 보장의 불확실성
   - 요청과 응답이 동시에 일어나지 않아, 요청의 처리 속도에 따라 응답순서가 뒤바뀔 수 있습니다.
3. 에러 처리 복잡
   - 요청과 응답이 분리되어 있어, 에러가 발생했을 때 원인을 파악하고 처리하기가 어렵습니다.

3. 동기 및 비동기 처리의 예시

동기 처리의 예시

상품 상세 페이지 로딩

• 설명: 사용자가 상품 목록에서 특정 상품을 클릭하면, 상품의 상세 정보 페이지로 이동합니다. 이때 전체 페이지가 새로고침되며, 새로운 URL로 이동하여 서버에서 상품에 대한 전체 HTML 페이지를 받아옵니다.
• 동작: 전체 페이지가 서버로부터 응답을 받아 로딩되기 전까지 사용자는 다른 작업을 할 수 없습니다. 이는 요청이 완료될 때까지 기다려야 하기 때문입니다.
• 예시 코드: 동기 방식의 폼 제출
  

  <form action="/order" method="POST">
      <input type="hidden" name="productId" value="12345">
      <button type="submit">Buy Now</button>
  </form>

  
  사용자가 Buy Now 버튼을 클릭하면, 페이지가 서버에 요청을 보내고 응답을 받아 새로고침됩니다. 이 과정은 동기적으로 진행되며, 서버 응답이 오기전까지 다른 작업을 할 수 없습니다.

비동기 처리의 예시

장바구니에 상품 추가

• 설명 : 사용자가 특정 상품을 장바구니에 추가할 때, 페이지가 새로고침되지 않고, 해당 상품이 비동기적으로 서버에 추가 요청을 보낸 후, 장바구니의 상태를 업데이트합니다.
• 동작 : 서버로부터 응답이 도착하기 전에도 사용자는 쇼핑몰에서 다른 상품을 검색하거나 추가할 수 있습니다. 서버에서 장바구니 업데이트 응답이 오면, 화면의 일부만 업데이트 응답이 오면, 화면의 일부만 업데이트되거나 알림이 표시됩니다.
• 예시 코드: 비동기 방식의 상품추가

const addToCart = (productId) => {
    axios.post('/cart', { productId: productId })
        .then(response => {
            cartProductList(response.data);
        })
        .catch(error => {
            console.error('추가되지 않음:', error);
        });
};

사용자가  addToCart 버튼을 클릭하면, 페이지가 새로고침되지 않고 장바구니에 상품이 비동기적으로 추가됩니다.
서버 응답이 오면 List를 받아 추가 처리를합니다. 그 사이 사용자는 다른 작업을 할 수 있습니다.

1. REST의 구성

1) 자원(RESOURCE) - URI (Uniform Resource Identifier)

 - 자원은 REST에서 관리하는 모든 데이터를 의미합니다. 에를 들어, 사용자 정보, 게시글, 상품 등… 다양한 내용이 자원이 될 수 있습니다. 자원은 특정 위치를 URI로 표현합니다.

 - URI란? : 인터넷 상에서 자원을 식별하는 고유한 주소입니다. 웹 브라우저에서는 URL 등으로도 많이 알려져 있습니다.

 URI를 통해 클라이언트는 서버의 자원에 접근할 수 있습니다.

예시 : /users/j-plum   - ID가 j-plum이라는 사용자에 대한 자원

/products/12345678  - ID가 상품번호가 12345678인 상품에 대한 자원.

(예시의 users와 products가 자원이되고 , 각각의 ID는 특정 자원을 식별하는 데 사용합니다.)

2) 행위(Verb) - HTTP Method

- 행위는 자원에 대해 수행할 동작을 정의합니다. REST 에서는 이 동작을 HTTP 메서드로 표현합니다.

HTTP 메서드는 클라이언트가 서버에 요청을 보낼 때 사용하는 규칙입니다.

- HTTP Method란? : HTTP Method는 클라이언트 서버 간의 상호작용을 정의하는 표준 방법입니다.

• GET : 자원을 조회할 때 사용합니다. (서버의 데이터를 가져올 목적)
  • 예시 :  GET /users/j-plum - ID가 j-plum인 사용자의 정보를 가져옵니다.
• POST : 새로운 자원을 생성할 때 사용합니다.
  • 예시 :  POST /users - 새로운 사용자를 생성합니다.
• PUT  : 자원을 업데이트(수정)할 때 사용합니다.
  • 예시 : PUT /users/j-plum  - ID가 j-plum인 사용자의 정보를 수정합니다.
    같은 URI라도 HTTP 메서드(GET, POST, PUT, DELETE)에 따라 서버가 수행하는 작업은 다릅니다
• DELETE : 자원을 삭제할  때 사용합니다.
  • 예시 : DELETE /users/j-plum -  ID가 j-plum인 사용자를 삭제합니다.

추가 내용

- 동일한 URI를 사용하더라도 HTTP 메서드에 따라 서버가 수행하는 작업은 다릅니다

( 위의 예시는 /users/j-plum 라는 URI를 반복해서 사용하고 있습니다. )

동일한 URI를 사용하는 장점

장점

1. 간결함 : 동일한 URI를 반복적으로 사용하면서, URI를 간소화하고 가독성을 높일 수 있습니다. 이로 인해 URI의 구조가 복잡해지지 않으며, 이해하기 쉬운 API를 설계할 수 있습니다.
2. 의미 전달 : URI와 HTTP 메서드를 조합함으로써, 자원에 대한 조작 의도를 명확하게 전달합니다. 예를 들어, /users/j-plum URI는 특정 사용자를 나타내며, GET, PUT, DELETE 메서드를 통해 조회, 수정, 삭제와 같은 다양한 작업을 수행할 수 있음을 직관적으로 알 수 있습니다.

• GET /users/j-plum: j-plum이라는 사용자의 정보를 조회합니다.
• PUT /users/j-plum: j-plum이라는 사용자의 정보를 수정합니다.
• DELETE /users/j-plum: j-plum이라는 사용자를 삭제합니다.

3) 표현(Representation) 

 - 표현은 자원의 상태나 데이터를 전달하는 방식을 의미합니다. 서버는 클라이언트의 요청에 따라 자원의 상태를 다양한 형식으로 반환할 수 있습니다. 주로 JSON이나 XML형식으로 표현됩니다.

 - 표현이란? : 표현은 자원의 실제 데이터를 포험하며, 이를 통해 클라이언트는 서버로부터 자원의 상태를 확인하거나 필요한 데이터를 받을 수 있습니다. 표현은 자원의 구조와 내용을 설명합니다.

예시 :  만약 사용자가 /users/j-plum URI에 GET 요청을 보내면, 서버는 ID가 123인 사용자의 정보를 반환합니다. 

{
  "id": j-plum,
  "name": "JJ",
  "email": "j.plum@gmail.com"
}

2. REST의 특징

1) Uniform Interface (유니폼 인터페이스)

 - Uniform Interface는 클라이언트가 서버 리소스와 상호작용하는 방식을 일관성 있게 정의합니다. 이로 인해 클라이언트는 URI로 지정된 리소스에 대한 작업을 통일되고 제한적인 인터페이스를 통해 수행할 수 있습니다.

예시 :  만약 사용자가 /users/ j-plum URI에 GET 요청을 보내면, 서버는 ID가 j-plum인 사용자의 정보를 반환합니다. 이때 모든 리소스에 대해 GET, POST, PUT, DELETE와 같은 HTTP 메서드가 일관되게 사용됩니다.

2) Stateless (무상태성)

 - REST는 무상태성을 지니고 있어 서버는 클라이언트의 이전 요청에 대한 정보를 저장하지 않습니다. 즉, 각 요청은 독립적으로 처리되며, 서버는 요청을 받을 때 필요한 모든 정보를 요청 본문이나 URL에서 받아야 합니다.

 만약 사용자가 POST /login 요청을 통해 로그인했다면, 서버는 이후 요청에서 이 사용자의 로그인 상태를 기억하지 않습니다. 클라이언트는 이후의 요청에서 인증 토큰 등을 헤더에 포함시켜야 합니다.

조금 더 자세하게 정리해 보겠습니다.

REST의 무상태성 원칙은, 서버가 클라이언트의 상태를 저장하지 않는다는 것을 의미합니다.

이 원칙에 따라, 각 요청은 독립적이며 자급자족적인 정보를 포함해야 합니다. 서버는 이전 요청의 상태나 세션정보를 기억하지 않으며, 클라이언트로부터 받은 각 요청을 그 자체로 완전한 정보로써 처리합니다.

1. 독립적  : 독립적이라는 것은 각 요청이 다른 요청과 연관되지 않는다는 것을 의미합니다. 하나의 요청이 다른 요청의 상태나 결과에 의존하지 않는다는 뜻 입니다.

2. 자급자족적  : 각 요청이 서버가 요청을 처리하는 데 필요한모든 정보를 포함하고 있어야 한다는 것을 의미합니다.

서버는 그 요청만으로 작업을 수행할 수 있어야 하며, 추가적인 상태 정보를 기억할 필요가 없습니다.

여기서 의문점이 생겼습니다

어... GET /users/j-plum 를 통해 j-plum 의 정보를 가져와사 그 정보를 이용해서 다른 API를 이용한다면

독립적인게 아니지않나..? 서로 의존하는 것 같은데.??

이는 클라이언트의 관점에서 입니다.

REST 의 무상태성(Statless)의 원칙과 독립성은 서버 관점에 바라봐야 합니다.

클라이언트 입장에서는 첫 번째 호출에서 얻은 데이터를 통해 두 번째 API를 호출하기 떄문에, 두 요청이 서로 의존하는 것 처럼 보일 수 있습니다.

서버 입장에서는, 각각의 요청이 독립적이고 자급자족적입니다.

서버는 첫번째 요청과 두번째 요청이 서로 관련이 있는지 알 필요가 없고, 기억하지 않습니다.

서버는 필요한 정보를 해당 요청에서 직접 받아 처리합니다.

3) Cacheable (캐시 가능)

 -  RESTful 서비스는 HTTP 프로토콜을 기반으로 작동합니다. HTTP는 웹 브라우저와 서버가 데이터를 주고 받는 방식에 대한 규칙입니다. 그 중 하나가 캐시(cache) 기능입니다.

캐시란?

- 캐시는 자주 사용하는 데이터를 임시로 저장해 두었다가, 다시 필요할 때 빠르게 꺼내 쓰는 메커니즘입니다.

예를들어, 웹 사이트에 접속할 때 이미 한 번 본 이미지를 매번 서버에서 다시 받아오지 않고, 브라우저가 임시로 저장해 둔 이미지를 재사용 하는것이 캐시 입니다.

그렇다면 RESTful 서비스에서의 캐시는?

 - RESTful API는 이런 캐시 기능을 활용할 수 있습니다. 서버는 리소스가 캐시될 수 있는지를 브라우저에게 알려줍니다.

이때 사용되는 것이 HTTP 헤더입니다

HTTP 헤더란?

 - HTTP 헤더는 클라이언트(브라우저)와 서버간의 통신에서 추가적인 정보를 담은 메세지 입니다. 

요청이나 응답과 함께 전달됩니다.

캐시 관련 HTTP 헤더 예시

• Chahe-control : 서버가 브라우저에게 리소스를 캐시할 수 있는지, 캣할 수 있다면 얼마나 오래 저장할 수 있는지를 알려줍니다.
  • 예시) Cache-Control : max-age=3600   => 이 리소스를 1시간동안  캐시할 수있다는 의미입니다.
• Expires : 캐시된 리소스가 언제 만료되는지를 나타냅니다.
  • 예시) Expires : wed, 21 Oct 2024 01:01:00 GMT   => 이 시간 이후로는 캐시를 사용하지 않고, 서버에서 다시 받아야 한다는 의미입니다.

상황 예시

상황 1 : 자원 요청하기

1. 사용자가 웹사이트에서 제품 목록을 보려고 합니다.
2. GET /products 를 서버에 요청
3. 서버는 제품 목록을 응답하며, Cache-Control : max-age=600 이라는 HTTP 헤더도 같이 보냅니다.(10분간 캐시가능)
4. 브라우저는 10분 동안 이 데이터를 저장해두고, 그 시간 내에 다시 요청이 오면 서버에 가지 않고 저장된 데이터를 바로 보여줍니다.

캐시된 데이터를 사용하는 과정

• 사용자가 10분 이내에 다시 동일한 GET /products 요청을 보낸다면, 브라우저는 먼저 캐시를 확인합니다.
• 캐시에서 GET /products 라는 키를 찾습니다. 이 키가 존재하고, 캐시된 데이터가 여전히 유효하면, 브라우저는 서버에 요청을 보내지 않고 바로 캐시된 데이터를 사용자에게 보여줍니다.
• 이로 인해 페이지 로딩 속도가 빨라지고, 서버의 부하도 줄어드는 장점이 있습니다.

캐시 만료 후

• 설정된 유효 시간이 만료되면 더 이상 유효하지 않으므로, 브라우저는 다시 서버에 GET /products 요청을 보내고,
  최신 데이터를 받아옵니다.
• HTTP 헤더의 내용에 따라 다시 캐

3줄요약

1. 브라우저는 GET /products 라는 요청을 키로, 응답 데이터를 값으로 캐시에 저장힙니다.
2. 동일한 요청이 시잔 내에 발생하면, 브라우저는 캐시에 저장된 데이터를 서버에 다시 요청하지 않고 바로 사용자에게 제공합니다.
3. 이는 서버와 브라우저가 캐시 관련 정보를 HTTP 헤더를 통해 주고받으면서 이루어지는 내용입니다.

4) Self-descriptiveness (자체 표현 구조)

 -  REST API 메시지는 자체 설명 구조를 가지고 있어, 클라이언트가 별도의 문서 없이도 API의 요청 및 응답을 이해할 수 있습니다. 이 구조 덕분에 시스템은 더 직관적이고 유지보수가 쉬워집니다.

예시 : 서버가 JSON 형식으로 {"userId": j-plum, "name": "Euang", "role": "admin"}와 같은 응답을 반환하면, 클라이언트는 이 메시지의 내용만 보고도 어떤 데이터가 포함되어 있는지 쉽게 이해할 수 있습니다.

5) Client-Server 구조

 - REST 아키텍처는 클라이언트와 서버를 분리된 구조로 설계합니다. 클라이언트는 사용자 인터페이스 및 사용자 경험을 담당하고, 서버는 데이터 저장 및 비즈니스 로직을 처리합니다. 이로 인해 두 시스템의 독립성이 높아집니다.

예시 : 클라이언트 애플리케이션은 Angular나 React 같은 프론트엔드 프레임워크로 구현되고, 서버는 Node.js나 Django 같은 백엔드 프레임워크로 구현될 수 있습니다. 클라이언트와 서버는 명확히 분리되어 있어 각자의 역할에 집중할 수 있습니다.

6) 계층형 구조

 - REST 서버는 여러 계층으로 구성될 수 있으며, 이를 통해 보안, 로드 밸런싱, 암호화 등 다양한 기능을 추가할 수 있습니다. 이 구조는 클라이언트와 서버 사이에 프록시나 게이트웨이 같은 중간 매체를 사용할 수 있게 합니다.

예시 : 클라이언트는 서버와 직접 통신하는 대신, 먼저 게이트웨이 서버를 통해 요청을 보냅니다. 이 게이트웨이 서버는 요청을 처리하거나 추가적인 보안 계층을 추가한 후 실제 서버로 요청을 전달합니다.

inpa dev - rest api 정리

https://inpa.tistory.com/entry/WEB-%F0%9F%8C%90-REST-API-%EC%A0%95%EB%A6%AC

<meta> 태그는 <Link>, <style>, <script> , <title> 등의 태그로 나타낼 수 없는 나머지 모든 정보를 표시할 때 사용합니다

meta는 정보를 의미

<meta name="author" content="J-plum" />

• name : 정보의 종류
• content : 정보의 값

<meta name="viewport" content="width=device-width, initial-scale=1.0" />

• 모바일에서 웹 페이지의 width를 모바일 환경의 width와 일치 시키거나, 웹 사이트가 처음 출력될 떄
  확대/축소 여부 정도 등 몇 가지 정보를 meta 태그로 명시하는 개념이 name="viewport"입니다.
• 데스크톱의 width와 device(모바일)의 width를 일치시킨다는 의미입니다.
• initial=sacle : 1.0배수로 보여주겠다는 의미입니다.(확대/축소의 여부)

비트맵(Bitmap)

• 픽셀이 모여 만들어진 정보의 집합, 레스터(Raster) 이미지 라고도 부름.
• 정교하고 다양한 색상을 자연스럽게 표현.
• 확대/축소 시 계단현상, 품질 저하.

1. JPG(JPEG)

• 압축률이 훌륭해 사진이나 예술 분야에서 많이 사용
• 손실 압축을 사용 (반복 저장시 손실이 일어남)
• 표현 색상도 (24비트, 약 1600만 색상) 이 뛰어남
• 이미지의 품질과 용량을 쉽게 조절 가능
• 가장 널리 쓰이는 이미지 포맷

2. PNG

• Gif의 대체 포멧으로 개발됨
• 비손실 압축
• 8비트 (256 색상) / 24비트(약 1600만 색상) 이미지 처리
• Alpha Channel 지원(투명)
• W3C권장 포맷

3. GIF

• 이미지 파일 내에 이미지 및 문자열 같은 정보들을 저장
• 비손실 압축
• 여러 장의 이미지를 한 개의 파일에 담을 수 있음(움짤, 애니메이션)
• 8비트 색상만 지원 (다양한 색상 표현에는 적합하지 않음)

4. WEBP

• JPG, PNG, GIF를 모두 대체할 수 있는 구글이 개발한 이미지 포맷.
• 완벽한 손실/비손실 압축 지원
• GIF같은 애니메이션 지원
• Alpha Channel 지원(손실, 비손실 모두)
• IE 지원 불가😕

벡터(Vector)

점, 선, 면의 위치(좌표), 색상 등 수학적 정보의 형태(Shape)로 이루어진 이미지.

확대/축소에서 자유로움, 용량 변화가 없음.

정교한 이미지(인물, 풍경)사진 을 표현하기 어려움