server (11) 썸네일형 리스트형 Server의 배포 문제 LocalHost3000 은 안보이지만 goggle.com 은 보이는 이유 상황 AJAX(AsynChronous JavaScript and XML) 비동기적으로 데이터 호출이 가능하기 때문에 파일의 크기가 커짐 그렇기 때문에 파일을 분리하는 모듈화를 해야함 이러한 모듈을 묶어주는 "번들링"을 웹팩, 바벨로 빌드를 해야함 그러면 이렇게 빌드된 정적파일을 호스팅 서비스에 결과물만 업로드 그 결과 웹 서버가 정적파일을 웹 어플리케이션에서 나의 사이트를 랜더링할 수 있음 네트워크의 작동원리 (캡슐화 비캡슐화) 네트워크의 계층(물리계층) 네트워크의 계층에는 크게 5가지로 나뉜다. 1. 응용계층 2. 전송계층 3. 네트워크 계층 4. 데이터 계층 5. 물리계층 여기서 우리가 먼저 넘어가야할 부분은 네트워크를 통해 데이터가 넘어간다? 라고 쉽게 말할 수 있지만 절대 그렇지 않다. 우리가 말하는 01010 데이터는 전기신호로 바뀌어서 전달되 나중에 설명하게 될 스위치, 라우터를 통해서 전기신호에서 데이터 신호로 바뀌게 된다. 내가 이 말을 왜 했을까? 이러한 데이터를 전기신호로 바꿔주는 것이 물리 계층의 역할하기 때문이다. 물리계층에서 데이터로 바뀐 01010 이 숫자들은 이제 어떻게 될까?(데이터 계층) 이러한 숫자들은 이제 적절한 확인 작업들을 진행하게 될 것이다. 정말 수신하는 컴퓨터가 원하는 데이터인지 송신하.. 브라우저 가동 원리 cache 상황 만약에 어떤 똑같은 이미지를 계속 요청을 한다면 계속 네트워크에 요청해서 받아야 할까? 해결 HTTP/1.1 200 OK content Type image/jpeg Cache-control: max-age=60. (60초 동안 캐시에 유지시켜줌) Content-Length=34012 브라우저 속도가 빨라짐 => 빠르게 데이터를 볼 수 있기 때문에 사용자 경험이 좋아짐 캐시 덕분에 네트워크 사용 x 문제 if 캐시 시간 초과했을 때? 같은 이미지를 또 다운 받아야 하나? 해결 1.Hedaer에 추가 서버에서 Last-Modified : 2020 11월 10일 10:00(검증 값) 2.클라이언트에서 if-modifed-since (만약 이후에 바꼈니?) 3.서버에서 304 NOt found +헤더 메타.. HTTP HEADER 개념 represation header : Content-Type. ex) application/JSON ( 어떤 형식으로 전달할지 모르기 때문에 알려줘야 함 ex) byte JSON html) Content-Length Content-Language. ex) ko en en-US content-negotiation : ex) 클라이언트가 해더로 /evnt GET /event ACCEPT-Language: ko 요청 협상과 우선순위 1. 언어 가중치에 따라 준다 2. 구체적인 것을 우선한다. =========================== 전송방법 1.Content-Encoding =gzip 2.Transfer-Encoding: chunked 방식 한번에 보내지 말고 나눠서 보내는거 이럴 때는 컨텐트 .. http 상태코드 개념 #200대 요청 정상 처리 #201 post 요청은 새로운 resource url가 생성이 됐구나 라고 알 수 있음 #300대 요청 완료를 위한 추가 행동 필요하다고 클라이언트에 응답을 보냄 영구적 redirection #301 코드 301코드+move permanently+ 새로운 url를 보내준다 ex) 새로운 이벤트 url 리다이랙션을 클라이언트에 날림 => POST로 요청하면 GET으로 바뀜 #308 코드 일시적 redirection #302 리다이렉트 요청시 get ex) POST로 주문 후 웹 브라우저로 새로고침하면?? 중복주문이 되기 때문에 해결) "주문 결과가 잘 됐습니다" 라는 get 응답을 해준다. 순서: 1. 마우스 주문 2. DB에 데이터 저장 3. 302 found를 보냄 l.. 회원관리 시스템 상황 url = resource 그 자체 "미네랄을 캐다 " 가 아니다 미네랄 그 자체 ex) 회원 목록 get 회원 등록 post 회원 조회 get 회원 삭제 회원 수정 put patch put 은 기존꺼를 아예 지우고 새롭게 만들기 때문에 부분 수정을 위한 patch 를 쓰는게 좋다. 만약 게시글을 전체 수정한다고 하면 put 을 쓰면 된다. 문제 신규 회원을 등록하고 싶을 때 해결 POST 방식 1./members url 에 post 방식으로 보내면 2. server가 /members/100 이라는 새로운 url 를 생성한다. (콜랙션) PUT방식 1. 클라이언트가 /mombers/{filename} (스토어 관리) HTML FORM 사용 control url ex) /new /edit /delete HTTP API URL 설계 문제: 회원에 대한 조회 url는 리소스를 판별하는데 무조건 써야함(명사) ex) 미네랄 그 자체 , 미네랄을 캐라가 아니다. 해결 HTTP 매서드를 이용해 동사를 표현( get, put post...) 1.GET 2.POST 메세지 바디를 통해 서버로 내 요청 데이터 전달( 서버가 아직 식별하지 않은 새 리소스 생성) ex) member 리소스 ex) 신규데이터 등록, 요청 데이터를 신규리소스 3.PUT 기존에 데이터가 완전히 대체되어버림. 만약에 없으면 새롭게 데이터 생성 4. PATCH 부분 변경 5. DELETE 매서드의 속성 1.안전 :해당 리소스를 호출하는 거기 때문에 2.멱등 : 100번 호출 하든 결과가 똑같다. POST는 멱등하지 않다. ex) 배송 2번 호출, 결제 (어떤 요청을 했어도.. 이전 1 2 다음
