[꼼꼼한 개발자] 꼼코더

🌐 Host (요청) 요청한 호스트 정보(도메인) 필수 헤더(아주 중요!!) 하나의 서버가 여러 도메인을 처리해야 할 때(하나의 IP 주소에 여러 도메인이 적용되어있을 때) 사용 🧑🏻‍🏫 예제 1) 가상 호스트를 통해 여러 도메인을 한 번에 처리할 수 있는 서버가 있음 서버의 IP주소가 200.200.200.2이다. 서버 안에 여러 개의 애플리케이션이 다른 도메인으로(aaa.com, bbb.com, ccc.com) 구동되어 있다. 2) 클라이언트가 Host를 지정하지 않고 서버에 /hello 요청을 보내는 경우 서버는 /hello가 aaa.com, bbb.com, ccc.com 중 어떤 도메인에 관한 요청인지 구분이 불가하다.(IP로 통신하기 때문) 3) 클라이언트가 Host를 지정하고 서버에 /hell..

📩 HTTP 메시지 전송 방식 👀 단순 전송 Content-Length 설정 데이터 전체를 한 번에 보낼 때 사용 다시 말해 Content의 길이를 지정을 해서 한 번에 요청을 하고 응답을 한다. 📩 압축 전송 Content-Encoding 설정 전송해야하는 데이터가 커서 압축해서 보낼 때 사용(압축 방식은 다양함) Content를 압축할 때 무엇을 압축되어 있는지 알아야 클라이언트에서 알고 압축을 풀 수 있다. 📨 분할 전송 Transfer-Encoding:chunked 설정, Content-Length 설정X 대용량 데이터를 클라이언트에 보낼 때, 요청이 모두 처리되기 전까지 총 크기를 알 수 없을 때 사용 chunked는 덩어리라는 뜻이다. 덩어리로 나눠서 전송을 한다. 그림을 설명 하자면 5byt..

🤝 콘텐츠 협상(Contents Negotiation) 클라이언트가 선호하는 표현 요청 협상 헤더는 요청시에만 사용 클라이언트 별로 선호하는 표현을 서버에서 처리해서 줄 수 있음 즉 클라이언트가 원하는 표현을 달라고 서버에 요청시 서버가 클라이언트가 원하는 우선순위에 맞춰서 표현 데이터를 만들어서 전송. 1) Accept: 클라이언트가 선호하는 미디어 타입 전달 2) Accept-Charset: 클라이언트가 선호하는 문자 인코딩 3) Accept-Encoding: 클라이언트가 선호하는 압축 인코딩 4) Accept-Language: 클라이언트가 선호하는 자연 언어 💬 Accept-Language 1) Accept-Language 적용 전 한국어 브라우저를 사용하고 다중 언어 지원하는 서버를 사용한다고 가..

표현 http로전송할 때, 어떠한 리소스를 html / json 등으로 표현해 전달한다. 과거 RFC2616 스펙에서는 엔티티헤더, 엔티티 본문 등으로 불리던 HTTP 헤더와 바디는 2014년부터 개정된 RFC2730~7235부터는 표현(Representation)이라는 용어로 불리게 되었다. HTTP 헤더는 표현 헤더, HTTP Message Body는 표현 데이터라 부른다. 표현 헤더 역시 표현 메타데이터와 페이로드 메세지로 구분해야 하지만, 생략한다. 🎃 표현 헤더 표현 헤더는 요청, 응답 메세지에서 모두 사용 1) Content-Type: 표현 데이터의 형식 2) Content-Encoding: 표현데이터의 압축 방식 3) Content-Language: 표현 데이터의 자연 언어 4) Conten..

👦🏻 HTTP 헤더 🎃 헤더 용도 HTTP 전송에 필요한 모든 부가정보를 담는 용도로 사용된다. 부가정보 : 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트, 서버 정보, 캐시 관리 정보 표준 헤더가 너무 많음, 필요시 임의의 헤더 추가 가능 >HELLO_WORLD: catsbi 🧙🏻‍♂️ 헤더 분류-RFC 2616(과거) 1) General 헤더: 요청/응답 메시지 전체에 적용되는 정보 > Connection: close 2) Request 헤더: 요청 정보 > User-Agent: Mozilla/5.0 3) Response 헤더: 응답 정보 > Server: Apache 4) Entity 헤더: 엔티티 바디 정보 > Content-Type: text/html, Content-..

👨🏻‍🏭 3xx (Redirection) 요청을 완료하기 위해 유저 에이전트(웹 브라우저)의 추가 조치 필요 300 : Multiple Choices 301 : Moved Permanently 302 : Found 303 : See Other 304 : Not Modified 307 : Temporary Redirect 308 : Permanent Redirect 🧑🏻‍🏫 리다이렉션 이해 웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동(리다이렉트) 사용자가 예전 이벤트 페이지( /event) URL을 북마크 해두었는데 새로운 이벤트 페이지(/new-event) URL로 바뀐 경우, 사용자가 예전 이벤트 페이지에 접속해도 새로운 이벤트 페이지 URL로 ..

🔖 상태 코드 HTTP 상태코드는 클라이언트가 서버로 보낸 요청의 처리 상태를 응답에서 알려주는 기능이다. 1xx (Informational): 요청이 수신되어 처리중 2xx (Successful): 요청 정상 처리 3xx (Redirection): 요청을 완료하려면 추가 행동이 필요 4xx (Client Error): 클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수행할 수 없음 5xx (Server Error):서버 오류, 서버가 정상 요청을 처리하지 못함 👀 만약 모르는 상태 코드가 나타나면? 클라이언트가 인식할 수 없는 상태코드를 서버가 반환하면, 클라이언트는 상위 상태코드로(2xx에서 2를 뜻 함) 해석해서 처리한다. 미래에 새로운 상태코드가 추가되어도 클라이언트를 변경하지 않아도 됨 299..

리소스를 식별하여 리소스만으로 URI를 설계한다. 문서, 컬렉션, 스토어로 해결하기 어려운 상황의 경우, 컨트롤 URI를 사용한다. 🧑🏻‍🏫 HTTP API 설계 예시 3가지 POST 기반으로 등록, PUT기반으로 등록하는 2가지 경우의 특징을 아는 것이 중요하다. 대부분 POST 기반 신규 자원 등록 방법(컬렉션)을 많이 사용한다. 1) HTTP API - 컬렉션 POST 기반 등록 → 회원 관리 API 제공 2) HTTP API - 스토어 PUT 기반 등록 → 정적 컨텐츠 관리, 원격 파일 관리 3) HTML FORM 사용 웹 페이지 회원 관리 GET, POST 만 지원 👩🏻‍💼 API 설계 - POST 기반 등록 회원 관리 시스템 회원목록 : /members ➡️ GET 회원등록 : /members..