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는 비연결성과 연결성의 중간 지점이라고 생각해도 되는지요?" 이 두가지가 강의 도중 궁금하여 질문 남깁니다~!! 고맙습니다!!!!

보통 서버 에서 POST/PUT/PATCH 로 받아도, service의 로직에 따라 의미가 달라질텐데, (예를들어 PUT으로 받아도, 부분 수정이 가능하도록 짜는 경우?) 강의에서 말씀하시는 내용들은 HTTP Method의 단순 개념에 대해 말씀하시는걸까요??

안녕하세요 강의 너무 잘 듣고 있습니다! 상태코드와 관련해서 이를 어떻게 설정하는지 이해가 잘 되지 않습니다.. 예를들어 303 코드를 지정하려면 특정 post요청이 올 경우 특정 get으로 보내주어야 하는데 이에 대한 설정들은 어떻게 이루어지나요? 응답에 Location 헤더가 존재할 경우 알아서 3XX을 반환하는건가요..? 이제껏 개발자가 직접 지정하는 영역이 아니라 브라우저가 알아서 판단 후 내보낸다고 생각했는데.. 예를들어 말씀하신 것처럼 302가 아닌 303으로 지정하려면 어디에 어떠한 설정을 해주어야 하는건지 질문드립니다. 항상 좋은 강의 감사합니다.

안녕하세요강의 중 20살 이상인 경우에 통과하는 로직이 있는데 15살이 들어온 경우 5XX 가 아닌 다른 에러를 출력하라고 하신 부분에 대한 질문입니다. 위와 같은 경우에는 400 Bad Request 에러를 내야 하는 건가요 ?? 아니면 다른 대안이 있을까요??

안녕하세요. 영한님, 항상 좋은 강의 감사드립니다. 한가지 궁금한 점이 생겼는데요. 만약 http 통신을 하는 상황에서, 로그인을 한 후에 set-cookie로 발급받은 sessionId를 해커에게 탈취당하면 해커는 해당 sessionID를 이용하여 제 아이디로 로그인이 가능한 상황이 되는 건가요??

패치의 경우 멱등성을 갖지 않는 이유가 무엇인가요? 외부 요인에 의해 값이 변경되지 않는 이상 항상 같은 결과를 가져오는 것 아닌가요..?

안녕하세요 ㅎㅎ 강의를 보다가 또 다른 질문이 생겨서 이렇게 질문 남깁니다.ㅎㅎ 1. 유저A 가 유저 B의 order id를 요청하는 경우 URL-GET orders/2-(유저 B order id) 403,404? 어떤 상태 코드를 실무에서는 많이 쓰고 이유가 있을까요? 2. PRG POST /orders -주문 API 주문생성을 예로 들어 PRG를 중복 주문을 막기 위해 쓰신다고 하셨는데 혹시 그렇게 되면 주문생성 API 사용성이 떨어지는 문제는 없나요? 가령 모바일에서도 해당 API를 사용한다든지, 여러 클라이언트(모바일, 웹)등 에서 redirect 하려는 페이지가 다르다든지.. 차라리 서버에서 중복을 잘 막고 나머지는 클라이언트 처리하는 방식은 실무에서 자주 쓰는 방법은 아닌가요? 이번에도 좋은 강의 감사합니다. ㅎ

배달의 경우 여러가지 상태값[배달전, 배달 시작, 배달 끝]이 있을거 같은데 배달 상태의 변경의 의미가 있는 PATCH /orders/{orderId}/delivery/{배달 상태값} 같은 식으로 url을 만들어야 하는거 아닌가요??

안녕하세요 새로 나온 강의 잘 보고 있습니다.ㅎㅎ 강의를 보다 궁금한 점이 있어서 질문드립니다. 1.put vs post 강의에서 말씀하신 것처럼 주문의 배송 시작을 예로 들자면.. post /orders/{order-id}/start-delivery patch /orders/{order-id} - {deliveryStatus:start} (배송상태를 start로 바꾼다) 이렇게 두 가지 방법이 있을 것 같은데 혹시 어떤 방법이 더 낫고 이유를 알 수 있을까요? 배송 시작이라는 프로세스가 라이더 호출 등 복잡한 프로세스가 포함된다면 post가 나은 방식인가요? 2.resource 보통 api resource는 비즈니스 도메인과 비슷하게 구성하나요? 아니면 아예 독립적으로 구성을 하나요? 항상 좋은 강의 감사합니다. 

1. resource 요청 시, 웹 브라우저가 HTTP 메시지 생성 2. SOCKET 라이브러리를 통해 TCP/IP로 3way handshake를 실행해 서버와 연결한다. 3. 운영체제 TCP/IP 계층으로 데이터 전송을 하기 위해 데이터를 전달한다. 4. HTTP 메시지가 포함된 TCP/IP 패킷을 생성한다. 5. 패킷 정보가 인터넷으로 흘러간다. 6. 서버에 요청  패킷이 도착하여 패킷 껍데기는 버리고 HTTP 메시지를 서버가 해석한다. 7. HTTP 응답 메시지를 마찬가지 방식으로 패킷을 생성하여 응답 패킷을 전달한다. 8. 수 많은 노드들을 통해서 응답 패킷이 도착하게 되면 웹 브라우저가 HTML 렌더링하여 화면에 보여준다. 강의를 들으면서 요청 응답 흐름을 정리해보았는데, 제가 이해한 내용이 맞는지 여쭤보고자 글 남깁니다.

안녕하세요, 클라이언트 서버 구조 강의 파트를 학습하다 궁금한 점이 생겨 질문드립니다. 해당 강의에서 매번 언급하셨던 '클라이언트 서버'란 단순하게 물리적인 서버에 요청을하는 '클라이언트(사용자)'를 뜻하는 의미가 아닌 개발적인 측면에서 Front-end  서버를 의미하는 것일까요? 만약, 그렇다고 한다면 제 입장에서 이해하는 클라이언트 서버란  요즘 트렌드인 Vue, React, Angular(+ Svelte)와 같은 Front-end 라이브러리 또는 프레임워크를 사용하여 구현된 홈페이지로 생각을 해도 되는지 궁금합니다 그럼 클라이언트의 요청(Request)에 따른 응답(Response) 과정은 아래와 같은 구조를 띄지 않을까 합니다.(과정은 최대한 단순화 하였습니다.) Client <--Req/Res--> Client Server(프론트엔드 서버) <--Req/Res--> Server(HTTP API가 구현된 백엔드 서버(+ DB 서버))