44,000원
다른 수강생들이 자주 물어보는 질문이 궁금하신가요?
- 미해결모든 개발자를 위한 HTTP 웹 기본 지식
컬렉션과 스토어 질문드립니다.
안녕하세요. 컬렉션과 스토어 정리가 잘 되지 않아 질문드립니다. https://www.inflearn.com/questions/265095 를 읽고나서 조금 더 혼란스러워서요..ㅠㅠ 위 질문에서 DELETE /members/{memberid} 는 생성/관리의 역할을 서버가 맡고 있다고 보는것이 맞다라고 답변이 적혀있는데요. 강의에서는 PUT /files/{filename} 은 클라이언트가 리소스의 URI를 알고 관리하기 때문에 /files는 스토어라고 설명되고 있습니다. 형태만 봤을 땐 files나 members의 URI 형태나 처리하는 방식이 비슷해 보여서 정리가 되지 않습니다.ㅠPUT /files/{filename} 은 파일 자체를 만들어주는것이(생성)이 아니라서 스토어이고,DELETE /members/{memberid}는 멤버정보를 DB에 저장해서 하나의 회원을 생성/관리(수정,삭제)하기 때문에 컬렉션이라고 이해하면 될지요?그게 아니라면 파일도 결국 members처럼 파일정보를 넘겨서 파일은 서버에 저장하고, 파일정보는 DB에 저장하므로 서버에서 처리하는게 아닌가하는 의문이 듭니다.매번 답변해주셔서 감사합니다 :)
- 미해결모든 개발자를 위한 HTTP 웹 기본 지식
안전(Safe), 멱등(Idempotent) 관련하여 질문드립니다.
안녕하세요. safe와 멱등 개념을 확실히 이해하고 싶어서 질문드립니다. ---------------------------------------------------- - safe : 리소스를 변경하지 않는, 즉 읽기전용 메서드(GET, HEAD)를 말한다. - 멱등 : 특정 메서드를 여러번 호출하여도 결과가 같다. ---------------------------------------------------- - GET, HEAD : Safe하면서, 멱등하다.- POST : 리소스의 위치를 지정하지 않았을 때 리소스를 생성하는 등 데이터를 변경하고 새로 생성된 결과를 보내줄 수 있으므로 safe하지도 않고, 멱등하지도 않다.- PUT : 리소스의 위치를 클라이언트가 알고 있고, 같은 리소스를 생성하거나 수정하므로 동일한 데이터로 요청하면 결과가 같다.그러므로 safe하지 않지만, 멱등하다.- DELETE : 클라이언트가 지정한 리소스를 삭제, 즉 수정이 일어나지만 삭제라는 동일한 결과를 제공하므로 safe하지 않지만, 멱등하다.혹시 잘 못 이해한 부분이 있으면 답변 부탁드립니다.감사합니다 :)
- 미해결모든 개발자를 위한 HTTP 웹 기본 지식
강의 진행방향
제가 지금 spring 완전정복 로드맵을 한번에 결제하고 따라가는중인데 mvc 1,2편을 끝내고 jpa강의로 넘어가는게 낫나요 아니면 지금 시점에서 넘어가는게 나을지 궁금합니다
- 미해결모든 개발자를 위한 HTTP 웹 기본 지식
Cache-Control: must-revalidate 와 max-age의 차이
Cache-Control: must-revalidate 와 max-age의 차이가 궁금합니다. Cache-Control: max-age 또한 일정 시간이 지나 캐시만료 후 서버에 검증해야 하고, 캐시 유효 시간이라면 캐시를 사용한다는 부분이 must-revalidate와 똑같다는 생각이 듭니다. max-age는 프록시 서버에서 검증을 할수도 있어서 그 부분이 다른건가요? 어떤 차이점이 있는건지 궁금합니다.
- 미해결모든 개발자를 위한 HTTP 웹 기본 지식
Host
[질문 템플릿]1. 강의 내용과 관련된 질문인가요? 예2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? 예3. 질문 잘하기 메뉴얼을 읽어보셨나요? 예[질문 내용] 안녕하세요. Host관련 질문 드립니다. 가상 호스트를 사용하는 경우 네임서버 ( 도메인 서버 )에서 각 도메인을 나누어 받은 후 서브도메인과 함께 판별해서 각 아이피로 연결해 주고 해당 폴더로 들어가 시작 페이지를 ( index.html 등) 실행해 주는 것으로 알고 있습니다. ( 예 : 홈페이지 서버 ) 저의 질문은 위 제가 말한 방법과 다르게 Back-End 서버 ( 예를 들면 스프링 서버 )에서 따로 코딩을 해서 분기해 주는 방법이 있는 걸까요? 아니면 제가 말씀 드린 가상 호스트의 경우를 설명해 주신 것인지 궁금합니다. 정리하자면 Host 처리는 server 설정에서 하는지 아니면 java에서 해주는지 아니면 경우데 따라 둘 다 가능한지 질문 드립니다. 감사합니다!
- 미해결모든 개발자를 위한 HTTP 웹 기본 지식
비지니스 로직
[질문 템플릿]1. 강의 내용과 관련된 질문인가요? 예2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? 예3. 질문 잘하기 메뉴얼을 읽어보셨나요? 예[질문 내용]안녕하세요. 좋은 강의 감사합니다. url 설계시 post는 저장 수정하고 get은 조회를 한다는 기본 개념을 잘 알게되었습니다. 그런데 실제로 실무에서 비지니스 로직을 조회할 때, 단순한 조회, 저장이 일어나는 경우는 거의 없다고 생각됩니다. 예를 들면 로그인 하는 상황이라고 가정했을 때 입니다. 1. 로그인 시도를 위해 아이디 패스워드 여부를 조회한다. 2. 아이디 패스워드가 일치한다면 로그인 히스토리 등 각종 정보성 테이블에 update를 한 후 로그인 처리를 한다. 이런 경우에 클라이언트에서 get api 호출 후 리턴 값을 받아서 post api로 저장을 한 후 후속 처리를 한다면 api를 여러번 호출하는 상황이 발생하게 됩니다. 아래 두가지 시나리오 중 어떤 방식이 최적인지 궁금합니다. 1. 로그인 api 한번 호출 ( get or post로 한번 던진 후 모두 처리 ) - 아이디/패스워드 일치 여부 확인 ( 조회 ) - 타 서버에 흩어진 회원 정보 조회 및 병합 ( 조회 ) - 각종 정보 업데이트 ( 수정 ) - 토큰 처리 등등 2. 로그인 api 여러번 호출 - GET 아이디/패스워드 일치 여부 확인 - SOAP 타 서버에 흩어진 회원 정보 조회 및 병합 - POST 각종 정보 업데이트 - POST 토큰 처리 등등 설명이 부족할 경우 댓글 주시면 더 자세히 설명해 보도록 하겠습니다. 감사합니다.
- 미해결모든 개발자를 위한 HTTP 웹 기본 지식
HTML 질문
1. 첫번째 동그라미와 같이 만들려면 file : <input type ~ >이런게 붙어있어야 하는지 궁금합니다. 2. get방식으로 넘겨주면 쿼리형태?로 넘어간다 하셔서 다음과 같은 사이트가 있어 get방식으로 해보았는데 post와 똑같이 결과가 나왔습니다. 이유가 궁금합니다..!
- 미해결모든 개발자를 위한 HTTP 웹 기본 지식
UDP
영한님 께서 TCP는 이미 모두 구축되어 있고 데이터의 크기도 크고 무겁기 때문에 UDP를 손대서 사용하시라 하셨는데 이 전송계층에서 UDP와 TCP가 공존하는건가요? 아니면 TCP를 이용해 통신을 할때가 있는거고 UDP를 이용해 통신을 할때가 있는건가요? 그리고 UDP를 손대서 사용하시라 하셨는데 UDP에 관해서 손댈 점이 무엇인가요?
- 미해결모든 개발자를 위한 HTTP 웹 기본 지식
왜 리소스와 행위를 분리해야할까요??
영한님이 예시에서 들어주신 회원 목록 조회 /read-member-list이런 방식으로 API 설계를 하면 안되는 이유가 무엇인가요?
- 미해결모든 개발자를 위한 HTTP 웹 기본 지식
패킷의 순서
제가 패킷에 대해 공부했을때 패킷들은 꼬리표에 번호가 달려서 전달이 된다고 했는데 IP의 단점에서 말씀 하셨듯이 패킷이 순서대로 안올수 가 있나요? 안올시 그 경우는 무슨 경우인가요?
- 미해결모든 개발자를 위한 HTTP 웹 기본 지식
Stateful, Stateless 질문드립니다.
안녕하세요. 제가 이해한게 맞는지 확신이 서지 않아 질문 남깁니다. 인프런 강의 동영상을 예로 들었을 때, - 사용자가 인프런에 로그인 후, 동영상을 시청하다가 02분24초에 동영상을 종료 > 다시 재생 시 > stateful : - 사용자가 종료한 시점이 서버에 저장되어 있고, 다시 동영상을 재생시켰을 때 서버에서 동영상 정보 및 종료 시점 등을 받아와 종료한 시점부터 재생- 서버 증설 시 : #A 서버에 사용자 종료한 시점이 저장되어 있을 경우, #B서버에서는 종료한 시점을 보내줄 수가 없다. > stateless : - 다시 동영상을 재생시켰을 때, 동영상 정보 및 동영상 종료 시점 등의 정보를 같이 서버에 보내서 종료한 시점부터 재생3) 서버 증설 시 : 요청 시 정보를 보내므로, 서버 증설 시 문제가 되지 않는다.간단하게 이렇게 정리를 했는데 맞는건지 모르겠네요^^;; 잘못 이해한 부분이 있다면 답변 부탁드리겠습니다 :) 감사합니다.
- 미해결모든 개발자를 위한 HTTP 웹 기본 지식
조회시 GET이 아닌 POST를 쓰는 것이 나쁜 이유
[질문 템플릿]1. 강의 내용과 관련된 질문인가요? (예/아니오) 네 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 네 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) 네 [질문 내용]여기에 질문 내용을 남겨주세요. 조회할때는 GET을 쓰는 거라고 배웠고, 저 스스로도 설계할 때는 그렇게 해야겠다고 생각하고 있습니다. 하지만 실무에서 거의 모든 걸 POST로 API를 설계하셨던 분을 본적이 있어서 질문을 남기게 되었습니다. 설계한 분께는 제가 조심스럽게 물어보니까 개인적으로 쿼리 그대로가 보여지는 게 싫어서 POST로 쓴다고 하셨는데요, 그 분의 이유가 납득이 되지 않지만, 왜 POST가 아닌 GET을 쓰는 것이 옳은 방향인지 정확히 알고 싶어서 질문을 남기게 되엇습니다. 설계 원칙을 지키기 위한 이유 외에 뭐가 또 있을까요?
- 미해결모든 개발자를 위한 HTTP 웹 기본 지식
patch멱등성 관련 질문 2개입니다.
"PUT의 경우와 PATCH의 경우가 애매하긴 합니다만, PUT은 예를들면 AGE=30으로 계속 반복 호출하는 것이라고 생각하시면 됩니다. AGE에 30을 할당하는 행위는 몇번을 반복해도 항상 AGE가 30일 것입니다. PATCH는 반면에 AGE = AGE+1 이라고 생각하시면 됩니다. 이것은 호출될때마다 AGE의 값이 바뀌게 되겠죠. 그래서 PUT은 멱등, PATCH는 멱등하지 않다라고 합니다." 1. 위 글은 다른 분 질문에 달린 답변의 일부입니다. 여기서 이해가 되지 않는 점이 PUT은 AGE = 30처럼 덮어쓰는 행위라고 생각하면 된다고 하셨는데 PUT도 AGE = AGE+1로 반복적으로 덮어쓸 수 있는것 아닌가요? 이렇게 된다면 put도 계속 리소스가 변경되는 것 같은데 왜 멱등한 것인지 이해가 명확히 되지 않습니다. 2. 그리고 safe와 멱등의 차이점은 단순히 한 번 호출과 여러번 호출했을때의 차이점인 것인지 아니면 요청의 결과가 같다는것에 초점을 맞춰야할지 헷갈립니다... 여러번 호출해도 데이터가 변하지않는다는게 멱등인 것인지 아니면 요청의 의도가 계속 같다는 것이 멱등인것인지 궁금합니다.
- 미해결모든 개발자를 위한 HTTP 웹 기본 지식
ppt 사소한 수정사항
학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요.1. 강의 내용과 관련된 질문을 남겨주세요.2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요.(자주 하는 질문 링크: https://bit.ly/3fX6ygx)3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요.(질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG)질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요.=========================================[질문 템플릿]1. 강의 내용과 관련된 질문인가요? (예/아니오)2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오)3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오)[질문 내용]여기에 질문 내용을 남겨주세요. 중요한거는 아니지만 ppt에 사소한 오류가 있어서 말씀드려요. 프록시 캐시 도입 관련해서 p.53 부터 400ms가 0.5초로 되어있습니다. 중요한건 아니지만 영상, ppt에 많은 공을 들이셨던걸 알기에 글 남겨봅니다.
- 미해결모든 개발자를 위한 HTTP 웹 기본 지식
프록시 캐시 서버 와 CDN
프록시 캐시 서버와 CDN이 동일한 것인지 궁금합니다.
- 미해결모든 개발자를 위한 HTTP 웹 기본 지식
클라이언트-서버 간의 TCP/IP 통신
2:00 쯤, 클라이언트-서버 간의 TCP/IP 통신은 IP로만 통신을 한다고 설명해주셨는데 이에 대해 궁금한 부분이 있어 질문 드립니다. Q0. TCP/IP 통신 자체가 IP로만 통신하는 방법이라는 의미가 아니고, 예시처럼 이름기반 가상호스팅을 하는 상황에서는 IP와 Host 정보만을 가지고 통신을 할 수 있다는 의미이신건가요? (앞선 [챕터1. 인터넷 네트워크] 강의에서 TCP/IP 통신은 IP와 PORT 정보를 가지고 통신을 하며, 동일한 IP 내에서 PORT를 통해 프로세스를 구분한다는 설명과는 다른 부분이 있어 약간 혼동이 생겼습니다) Q1. 그럼 예시 상황에서 PORT 개념은 해당 통신에서 사용되지 않는건가요? 혹시 사용된다면 어떻게 사용되는걸까요?!
- 미해결모든 개발자를 위한 HTTP 웹 기본 지식
상태코드 질문
학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요.1. 강의 내용과 관련된 질문을 남겨주세요.2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요.(자주 하는 질문 링크: https://bit.ly/3fX6ygx)3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요.(질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG)질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요.=========================================[질문 템플릿]1. 강의 내용과 관련된 질문인가요? (예/아니오) 예2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 예3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) 예[질문 내용]여기에 질문 내용을 남겨주세요. 안녕하세요 좋은 내용의 강의 잘 듣고 있습니다. 상태코드는 앞서 HTTP 메서드 처럼 결국 일종의 약속으로 생각하고 강의를 듣고있는데 맞나요? 301의 경우 POST로 해도 GET으로 리다이렉트하고 본문 제거될 수 있고 이런게 개발할때 이를 참고해서 구현해주고 약속으로 정해져 있어서 다른 사람이 봐도 301번이니 이런 내용이겠구나 짐작할 수 있게하는것처럼요.
- 미해결모든 개발자를 위한 HTTP 웹 기본 지식
쿠키 생성 관련 질문드립니다!
안녕하세요! 쿠키는 서버에서 자동으로 생성하여 클라이언트로 전송하는 사용자의 정보인 것은 알았습니다. 질문1) 그런데, 클라이언트 측에서 먼저 쿠키를 생성하여 보내는 경우는 왜 그럴까요? 아래는 파이썬 requests 라이브러리를 통해 클라이언트에서 쿠키를 생성해 서버에 쿠키를 보내는 예시 코드입니다. url = 'https://www.google.com' cookies = dict(cookies_are='working') r = requests.get(url, cookies=cookies) 서버에서 쿠키를 만들텐데, 위의 예시처럼 쿠키를 클라이언트에서 만들면 사용자가 작성한 정보만 서버가 쿠키에 추가하는 것일까요? 질문2) 파이썬에서 request.Session()을 통해 세션을 생성할 수 있는데, 이 코드는 강의에서 설명해주신 세션 쿠키를 만드는 것과 동일한가요? 세션 쿠키가 아니라면 TCP 커넥션을 유지해주는 말그대로 세션의 역할을 하는 것일까요? 파이썬으로 실습을 하다보니 파이썬 코드로 질문을 드려 죄송합니다ㅠㅠ
- 미해결모든 개발자를 위한 HTTP 웹 기본 지식
세션 쿠키 질문 있습니다^^
쿠키의 생명 주기 설명에서 세션 쿠키: 만료 날짜를 생략하면 브라우저 종료시까지만 유지된다고 하셨는데, 웹서버 입장에서는 웹 브라우저가 종료되었다는 사실을 모를텐데 그럼 서버는 세션을 언제까지 보관하고 있나요?
- 미해결모든 개발자를 위한 HTTP 웹 기본 지식
웹 브라우저 요청 흐름 강의 중 HTTP 메시지 전송 과정에서 질문이 있습니다!
강의와 다른 질문들을 참고하여 HTTP 메시지 전송 과정의 순서에 대해 제가 이해한 내용은 아래와 같습니다. 1. 웹 브라우저에서 HTTP 메시지를 생성한다. 2. 애플리케이션은 소켓 라이브러리를 사용하여 TCP/IP와의 연결을 지시한다. 3. TCP/IP 와 연결된 후 TCP 계층에서 3 way handshake를 진행하여 서버와 연결한다. 4. 서버와의 연결이 확인되면 TCP/IP 프로토콜로 데이터(HTTP 메시지)가 전달된다. 5. TCP/IP는 전달받은 HTTP 메시지에 TCP관련 정보와 IP관련 정보를 추가하여 TCP/IP 패킷을 생성한다. 6. 웹 브라우저는 요청 패킷을 인터넷 망에 던진다. 질문입니다! Q1. 제가 이해한 전체 과정이 맞나요? Q2. 3 way handshake를 진행하는 계층과 시점이 헷갈리는데요. 3 way handshake는 TCP/IP 연결 후에 TCP 계층에서 진행되는 것이 맞나요? (애플리케이션 계층에서 일어나는 게 아닌 거죠?) Q3. 3 way handshaking을 하는 이유는 요청 패킷을 서버로 던지기 위해서 서버와의 연결을 확인하기 위한 게 맞나요? Q4. 강사님께서 3 way handshake 진행 전 찾았다고 언급하신 IP와 PORT는 HTTP 요청 메시지 생성 전 URL을 통해 찾은 PORT와 DNS 서버를 통해 찾은 IP인 게 맞나요? Q5. TCP/IP 패킷 생성 시 담아지는 IP와 PORT도 HTTP 메시지 생성 전에 URL과 DNS 서버 조회를 통해 찾아낸 IP와 PORT인 건가요?