강사님 안녕하세요:) 강의 내용 중 POST 예시에서 "기존 자료에 데이터 추가 ex) 한 문서 끝에 내용 추가하기" 에서 궁금한 점이 생겨 질문드립니다. 위 경우 저는 PATCH 나 PUT을 사용해서 /contents/{id} 이런식으로 기존 내용에 추가해야 할 것이라고 생각했는데, 왜 POST를 사용하는지 궁금합니다.  또한, POST를 사용할 경우 http body에 기존 문서의 id를 넣어서 전송해야 되는 것 맞나요? 그리고 뒤에 HTTP API 설계 예시 강의  "HTTP API -컬렉션 회원관리 시스템" 부분에서 PATCH와 PUT을 사용하기 애매한 경우에는 POST를 사용하여 수정하라고 하셨는데, 어떤 경우가 애매한지 궁금합니다("기존 자료에 데이터 추가"가 그 애매한 경우인가요..?). 쓰다보니 질문이 많아졌네요,,ㅜ 강의를 들으면서 많이 배우고 있습니다. 정말 감사합니다!!

안녕하세요 강사님, 질문 드리겠습니다. 클라이언트가 서버에게 요청할 uri를 설계하는 것이 API 설계로 표현되었다면, 백엔드 개발자가 개발하게되는 모든 백엔드 로직들을 API라고 보면 되는 건가요? 지금까지 제게 있어 API는 그냥 남이 만들어놓은 것을 가져다 편리하게 쓸 수 있는 도구(ex 구글맵 API) 정도였는데요. 백엔드 개발자가 개발하는 서버 프로그램들도 API의 범주에 포함되는 것인가요? 감사합니다.

안녕하세요 영한님 모든 강의 잘 듣고 있는 수강생입니다! 다름이 아니라 이번에 HTTP 강의를 수강하기 시작하면서 PDF파일이 350이 넘는 방대한 양을 가지는 것을 알게되었습니다. 수강생 개개인 마다 학습 스타일이 다르다고 생각하지만 복습 하는 과정에서 제가 원하는 내용이 pdf의 몇 페이지에 있는지 찾는데 어려움을 느끼고 있습니다. 제가 기억하기로는 Spring jpa강의에서는 코드 중심의 교육 자료가 아닌 정보전달 위주로 준비하셨기에 챕터마다 구분된 PPT로 제공해주셨고 data jpa에서는 코드가 중요한 부분을 차지하고 있기 때문에 한 개의 pdf파일로 구성되었다고 생각합니다. 따라서 혹시 강의 자료를 PPT로 제공해주셔도 되고, 아니면 Spring jpa처럼 챕터를 구분하여 강의자료를 올려주실수 있는지 질문드립니다. 사실 data jpa 실전편 강의들을 때도 강의 자료가 하나의 pdf로 되어있어서 복습하고 싶은 부분이나, 까먹었던 부분 바로바로 찾아보기에 힘듦도 있습니다 ㅠㅠ 마지막으로 강의마다 강의자료의 기본 페이지 크기가 차이가 많이 나는듯 합니다. 요즘 pdf나 ppt를 노트앱에 저장해놓고 팬슬이나 키보드 사용해서 강의 내용을 받아 적으면서 공부하는데 기본 페이지 크기가 들쭉날쭉해서 강의 들을 때 마다 자료의 크기에 맞게 환경을 조정하니 자연스레 강의에 몰입하는데 시간이 좀 걸리는거 같아요 ㅠㅠ 혹시 기본 페이지 크기를 완벽하게 맞추지는 못하더라도 어느정도 균일하게 만들어서 제공해주시면 어떤지 생각합니다ㅠㅠ 두서가 상당히 없지만 항상 강의 잘 듣고 있습니다!

안녕하세요, 질문 드리겠습니다. 웹 통신에서는 강의에서 설명하시는 IP 4계층을 통해서만 통신이 이뤄지나요? 흔히 알려져있는 OSI 7계층과 완전히 개별적인 것인지 궁금합니다. 감사합니다. 

안녕하세요 김영한님. 강의를 듣다가, 문득 모바일의 경우에는 flow가 어떻게 되는지 궁금해져서 질문남깁니다. 인터넷에서 통신은 결국 IP와 Port번호를 알아야 data를 전송할 수 있는 것으로 이해하고 있습니다. 그런데, 모바일은 IP가 계속 바뀌고 Port번호를 따로 설정하지 않아도 카톡 메시지를 서버로 부터 수신할 수 있습니다. 검색을 통해, FCM이나 APNs과 같은 Push 서버를 이용해서 보낸다는 개념은 이해하였습니다만, 이 Push 서버들이 어떻게 바뀌는 모바일의 IP를 알아내는 건지, port 포워딩?은 어떻게 해결하는지 궁금합니다. 바쁘시겠지만, 답변남겨주시면 정말 감사하겠습니다.

안녕하세요 김영한님. Persistent Connection 질문입니다. 제가 간단한 웹 프로젝트를 운영하고 있는데, 자동으로 Persistent Connection가 적용된 것처럼 보입니다. 원래 따로 설정을 해주어야 적용이 되는 건지, g유니콘이나 그런 앱에서 알아서 처리를 해주는 건지, HTTP 자체적으로 기본설정이 되어 있는 건지,  궁금합니다!

안녕하세요. 좋은 강의를 보고 패킷모아 보내기를 테스트 해보고 있습니다. 강의와 같이 ServerSession을 500개 만들어서 테스트를 해보면 500개 까지 Connect가 안되고 400좀 넘어서 끝나버리는데(실행할때마다 달라요) 이게 피씨 사양과도 관련이 있나요? 아님 다른 이유가 있을까요? (선생님 파일을 받아서 실행해봐도 비슷해서요)

캐시 컨트롤 지시어가 no-store일때,  메모리에서 사용하고 최대한 빨리 삭제하라고 되어있는데, 저 메모리는 어디인가요? 보통, 캐시는 웹 브라우저상에 있는 저장공간에 저장되는거로 알고있는데, no-store일때 저장되는 메모리공간은 다른곳인가요? 

클라에서 서버로 요청 할 경우, 1. header에 cache-control의 max-age의 시간은 이미 만료 2. last modified date의 시점이 아직 변경되지 않은 시점일 때 서버에서 클라이언트로 보내주는 header 정보에 cache meta 데이터는 어떤 식으로 갱신이 되는건가요? 

웹 서버, 즉 http는 80번 포트로 연결된다고 알고있는데, 스프링 부트에서 동작하는 톰캣은 왜 8080번 포트로 연결되는 것이 기본값 인가요?

HTTP API를 기반으로 한 것이 REST API인가요? 무슨 차이가 있는지 궁금합니다.

로그인 유지를 위해 세션, 쿠키를 사용해 어쩔 수 없이 서버에 상태를 저장해야 된다고 하셨는데요! 그러면 세션과 쿠키를 사용했을 때에는 어떻게 서버를 증설할 수 있나요? 제가 생각해본 바로는 redis에 로그인 정보를 저장하는 방식으로 가능하다고 생각이 들었는데 맞는 방법일까요?? 그리고 토큰을 사용하면 로그인 관련해서도 무상태로 서버를 유지할 수 있는거 같은데 맞나요?? 명확하게 답이 나오지않아서 질문드립니다! 항상 좋은 강의 감사드립니다! 새해 복 많이 받으세요 ㅎㅎ

19:00 쯤 Player를 찾고 로그를 남기는 테스트에서 chatPacket.chat를 로그로 남긴 후에 GameObject를 Find할 때 메인 쓰레드에서 사용하라는 예외가 발생합니다. 혹시 제가 잘못 작업했나 해서 올려두신 자료를 받아서 해보아도 똑같이 try catch에서 넘어가질 못하네요 유니티 버전 2021.1.0b1에서 안되서 2019.4.17f1까지 낮춰봤는데도 안됩니다. 무언가를 빠트린거 같은데 찾기가 힘드네요 혹시 조언좀 해주실 수 있을까요 

안녕하세요 질문 드립니다. field name은 대소문자를 구분하지 않는다고 하셨는데 field value는 대소문자를 구분한다고 봐야 할까요? 실제로 GOOGLE.com으로 입력해도 google.com으로 열어주는데 브라우저의 기능일까요? 확인 부탁드려요~

이런 수업이 다른 곳에 없다보니 질문이 많게 되네요 ;;  저같은 경우 게시글 추가 API, 회원가입API 같은 경우 post method로 클라이언트에서 서버로 요청하고 서버는 그 요청에 성공적으로 응답할 때 200 상태코드와 함께  post_id나 user_id를 리턴하도록 하였습니다. 만약 헤더내의 location을 이용한다면 user_id, post_id까지 사용하지 않게 될테니 204로 리턴해도 되겠네요. 그런데 201 스펙처럼 클라에서 요청한 데이터값을 서버가 다시 리턴하는 이유가 있을까요? 왜냐하면 게시글추가라던지, 회원가입이라던지 어차피 클라이언트에서 보낸 데이터라 클라이언트에서 쿠키에 저장하면 될 것 같거든요. 불필요하게 서버에서 클라이언트에게 '클라이언트가 보낸 데이터'를 보낼 필요가 있는가에 대한 의문이 들어서 질문하게 되었습니다.

안녕하세요:) 결제 API에서 클라이언트와 서버 통신 예외처리에 대해 질문이 있습니다. 6분 34초경에 "클라이언트에서 유저가 페이지 리로드할 경우가 있어서 동일 주문이 서버에 요청이 될 수 있기 때문에 서버에서도 예외처리해놔야한다"고 하셨습니다. 제가 영한님의 말씀을 듣고 처음 생각난 방식은 클라이언트에서 주문번호를 난수로 만들어준 다음 쿠키에 저장하여서 동일한 주문번호를 서버에 요청했을 때 서버에서 거절하면 된다고 생각했은데, 클라이언트에서 주문번호를 자리수가 짧은 난수로 만들었을 때 중복되는 값이 발생할 것으로 생각이 드네요. 그래서 이 방법은 또 다른 이슈를 발생시킬 것 같아 좋은 방법은 아닌 것 같고... 2 번째로는 처음 생각한 방법을 응용한건데 난수를 유저테이블의 index와 구분자 그리고 현재 유닉스시간까지 숫자를 합쳐서 만들면 중복될 가능성이 낮아질 것 같다는 생각을 했습니다. 예) 12/1609305240 혹시 더 나은 방법이 있을까요? 8분30초 경에 말씀해주시는 주문 중복을 피하는 방법에 대해서는 이해했습니다! 

put이 지칭한 서버의 리소스를 새로 덮어씌우기 때문에 멱등한것은 알겠습니다. 그런데 patch도 지정된 리소스의 부분만을 접근해서 변경하는 행위를 반복하는건데 왜 멱등하지 않은지 궁금합니다. 어짜피 외부의 변경은 고려하지 않는다면 항상 같은 결과가 나올것이라고 보장할 수 있는거 아닌가요?

하위 호환을 위해서 Pragma : no-cache 헤더를 추가하는 것은 이해가 되는데. no-cache, must-revalidate  는 왜 추가하는 것인지 이해가 되지 않습니다. 데이터가 이미 캐시가 되어 있는 경우 또는 새로운 데이터를 응답하는 경우 모두 캐시를 무효화 시키고 싶다면 서버에서 no-store 로도 응답하면 되는 것아닌가요?

안녕하세요 강사님 좋은 강의 감사합니다! 질문이 2가지가 있는데요.1. 예를들어요청의 흐름이 다음과 같을 때 브라우저 -> Nginx -> Spring  Request Header 의 Accept-Langauge 가 ko 로 옵니다.그럼 서버에서는 1, 지원하는 language 가 뭔지 파악 2. accept-langauge 를 토대로 적절한 langague 로 본문을 응답이런 로직이 있어야 하는데 해당 로직은 WAS 에 개발자가 직접 로직을 작성해야 하는 것 맞나요? 2. 아래 그림의 Quality 값은 브라우저가 자동으로 넣어주는 값인가요? 아니면 개발자가 서버에 요청시 세팅해주는 값인가요?

선생님 강의 정말 잘 듣고 있으며 좋은 자료 또한 제공해주셔서 피상적이었던 지식이 구체화 되는 작업에 정말 도움이 많이 되고 있습니다.  다름이 아니라 지속 연결에 대해서 한 가지 궁금한 점이 생겨서 이렇게 질문 남깁니다. http 의 방향이 stateful -> stateless 이렇게 진화한다고 저는 이해했습니다. 진화한 이유는 클라이언트와 서버간의 연결을 계속 지속한다면 자원의 고갈이 일어나기 때문이죠! 그렇다면 지속연결이 탄생한 배경은 stateless가 자원의 고갈은 방지하나 여려번의 3 way handshake가 비효율적이기 때문에 이를 방지하고자 여러번의 3 way handshake의 횟수를 줄이기 위해서 하나의 연결이 지속될때 어느정도 까지는 쭈욱 유지하자 라고 이해했습니다! "그렇다면 Persistant Connections가 언제까지 유지되어야하는 그러한 규약같은건 따로 없는지요?" "또한 Persistent Connections는 비연결성과 연결성의 중간 지점이라고 생각해도 되는지요?" 이 두가지가 강의 도중 궁금하여 질문 남깁니다~!! 고맙습니다!!!!