모든 글은 다음 블로그를 참고하여 작성하였습니다.
https://gyoogle.dev/blog/

브라우저 동작 방법

요약

주소창에 url을 입력하고 Enter를 누르면, 서버에 요청이 전송됨
해당 페이지에 존재하는 여러 자원들(text,image 등등)이 보내짐
이제 브라우저는 해다 자원이 담긴 html과 스타일이 담긴 css를 W3C 명세에 따라 해석할 것임
이 역할을 하는 것이 ‘렌더링 엔진’
렌더링 엔진은 우선 html 파싱 과정을 시작함. html 파서가 문서에 존재하는 어휘와 구문을 분석하면서 DOM 트리를 구축
다음엔 css 파싱 과정 시작. css 파서가 모든 css 정보를 스타일 구조체로 생성
이 2가지를 연결시켜 렌더 트리를 만듬. 렌더 트리를 통해 문서가 시각적 요소를 포함한 형태로 구성된 상태
화면에 배치를 시작하고, UI 백엔드가 노드를 돌며 형상을 그림
이 때 빠른 브라우저 화면 표시를 위해 ‘배치와 그리는 과정’은 페이지 정보를 모두 받고 한꺼번에 진행되지 않음. 자원을 전송받으면, 기다리는 동시에 일부분 먼저 진행하고 화면에 표시함

	Cookie	Session
저장위치	Client	Server
저장형식	Text	Object
만료시점	쿠키 저장시 설정 (설정 없으면 브라우저 종료 시)	정확한 시점 모름
리소스	클라이언트의 리소스	서버의 리소스
용량제한	한 도메인 당 20개, 한 쿠키당 4KB	제한없음

HTTP status code

10x : 정보 확인
20x : 통신 성공
30x : 리다이렉트
40x : 클라이언트 오류
50x : 서버 오류
200번대 : 통신 성공

상태코드	이름	의미
200	OK	요청 성공(GET)
201	Create	생성 성공(POST)
202	Accepted	요청 접수O, 리소스 처리X
204	No Contents	요청 성공O, 내용 없음

300번대 : 리다이렉트

상태코드	이름	의미
300	Multiple Choice	요청 URI에 여러 리소스가 존재
301	Move Permanently	요청 URI가 새 위치로 옮겨감
304	Not Modified	요청 URI의 내용이 변경 X

400번대 : 클라이언트 오류

상태코드	이름	의미
400	Bad Request	API에서 정의되지 않은 요청 들어옴
401	Unauthorize	인증 오류
403	Forbidden	권한 밖의 접근 시도
404	Not Found	요청 URI에 대한 리소스 존재X
405	Method Not Allowed	API에서 정의되지 않은 메소드 호출
406	Not Acceptable	처리 불가
408	Request Timeout	요청 대기 시간 초과
409	Confilct	모순
429	Too Many Request	요청 횟수 상한 초과

500번대 : 서버 오류

상태코드	이름	의미
500	Internal Server Error	서버 내부 오류
502	Bad Gateway	게이트웨이 오류
503	Service Unavailbale	서비스 이용 불가
504	Gateway Timeout	게이트웨이 시간 초과

REST API

REST : 웹 (HTTP)의 장점을 활용한 아키텍쳐

REST 기본

REST의 요소
- Method | Method | 의미 | Idempotent | | :——: | :———–: | :—————: | | POST | Create | No | | GET | Select | Yes | | PUT | Update | Yes | | DELETE | Delete | Yes |
  
  Idempotent : 한 번 수행하냐, 여러 번 수행했을 때 결과가 같나?
- Resource
  - http://myweb/users와 같은 URI
  - 모든 것을 Resource (명사)로 표현하고, 세부 Resource에는 id를 붙임
- Message
  - 메시지 포맷이 존재 : JSON, XML과 같은 형태가 있음 (최근에는 JSON을 씀)
    1
    2
    3
    4
    5
    6
    HTTP POST, http://myweb/users/ { "users" : { "name" : "terry" } }
REST의 특징
- Uniform Interface
  - HTTP 표준만 맞는다면, 어떤 기술도 가능한 Interface 예) REST API 정의를 HTTP + JSON로 하였다면, C, Java, Python, IOS 플랫폼 등 특정 언어나 기술에 종속 받지 않고, 모든 플랫폼에 사용이 가능한 Loosely Coupling 구조
  - 포함
    - Self-Descriptive Messages
      - API 메시지만 보고, API를 이해할 수 있는 구조 (Resouce, Method를 이용해 무슨 행위를 하는지 직관적으로 이해할 수 있음)
    - HATEOAS(Hypermedia As The Engine Of Application State)
      - Application의 상태(State)는 Hyperlink를 통해 전이되어야 함.
      - 서버는 현재 이용 가능한 다른 작업에 대한 하이퍼링크를 포함하여 응답해야 함
    - Resource Identification In Requests
    - Resource Manipulation Through Representations
- Statelessness
  - 즉, HTTP Session과 같은 컨텍스트 저장소에 상태 정보 저장 안함
  - Request만 Message로 처리하면 되고, 컨텍스트 정보를 신경쓰지 않아도 되므로, 구현이 단순해짐
  - 따라서, REST API 실행 중 실패가 발생한 경우, Transaction 복구를 위해 기존의 상태를 저장할 필요가 있다. (POST Method 제외)
- Resource 지향 아키텍쳐 (ROA : Resource Oriented Architecture)
  - Resource 기반의 복수형 명사 형태의 정의를 권장.
- Client-Server Architecture
- Cache Ability
- Layered System
- Code On Demand(Optional)

Version 3.0

기술 면접 준비 (9) - Web (1)

브라우저 동작 방법

요약

HTTP status code

REST API

브라우저 동작 방법

요약

Cookie & Session

HTTP status code

REST API