http
-
http8:http 2022. 7. 27. 20:53
● 상태 코드 : 클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능 1xx (Informational) : 요청이 수신되어 처리중 2xx (Successful) : 요청 정상 처리 3xx (Redirection) : 요청을 완료하려면 추가 행동이 필요 4xx (Client Error) : 클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수행할 수 없음 5xx (Server Error) : 서버 오류, 서버가 정상 요청을 처리하지 못함 ⏺ 만약 모르는 상태 코드가 나타나면? -> 클라이언트가 인식할 수 없는 상태코드를 서버가 반환하면? -> 클라이언트는 상위 상태코드로 해석해서 처리 -> 미래에 새로운 상태 코드가 추가되어도 클라이언트를 변경하지 않아도 됨 (예) - 299 ??? -> 2xx..
-
http7:http 2022. 7. 13. 12:32
HTTP API 설계 예시 (2가지 종류 있어! -> POST, PUT) - HTTP API - 컬렉션 POST 기반 등록 예) 회원 관리 API 제공 - HTTP API - 스토어 PUT 기반 등록 예) 정적 컨텐츠 관리, 원격 파일 관리 - HTML FORM 사용 웹 페이지 회원 관리 GET, POST만 지원 자 [ 회원 관리 시스템 ] 을 만든다고 생각해봐 URI(리소스)를 식별하는건 -> 항상 리소스를 식별해야지 다른걸 식별하면 안돼! 회원 목록 /members -> GET 회원 등록 /members -> POST 회원 조회 /members/{id} -> GET 회원 수정 /members/{id} -> PATCH, PUT, POST (PATCH : 부분적으로 수정) (PUT : 완전히 덮기) (P..
-
http4:http 2022. 6. 16. 02:15
HTTP 메서드 활용 클라이언트에서 서버로 데이터 전송 - 전달 방식은 크게 2가지 1. 쿼리 파라미터를 통한 데이터 전송 ⏺ GET ⏺ 주로 정렬 필터(검색어) 2. 메시지 바디를 통한 데이터 전송 ⏺ POST, PUT, PATCH ⏺ 회원 가입, 상품 주문, 리소스 등록, 리소스 변경 - 4가지 상황 ⏺ 정적 데이터 조회 🔘 이미지, 정적 텍스트 문서 🔘 조회는 GET 사용 🔘 정적 데이터는 일반적으로 쿼리 파라미터 없이 리소스 경로로 단순하게 조회 가능해~ ⏺ 동적 데이터 조회 🔘 주로 검색, 게시판 목록에서 정렬 필터(검색어 같은 추가조건들 -> 쿼리 파마리터 사용 (q=hello&hl=ko)) 🔘 서버에서 쿼리 파라미터를 기반으로 정렬 필터해서 결과를 동적으로 생성 🔘 조회 조건을 줄여주는 필터..
-
http4:http 2022. 6. 15. 22:26
⏺ 🔘 HTTP 메서드 ->가장 중요한 것은 리소스 식별! - 리소스의 의미는? 🔘 회원을 등록하고 수정하고 조회하는게 리소스가 아니다 🔘 (예) 미네랄을 캐라 -> 미네랄이 리소스 🔘 회원이라는 개념 자체가 바로 리소스! - 리소스를 어떻게 식별하는게 좋을까? 🔘 회원을 등록하고 수정하고 조회하는 것을 모두 배제 🔘 회원이라는 리소스만 식별하면 된다. -> 회원 리소스를 URI에 매핑 요구사항 - 회원 정보 관리 API를 만들어라! -API URI 설계 : 리소스 식별, URI 계층 구조 활용 🔘 회원 목록 조회 / members 🔘 회원 조회 / members/{id} ->어떻게 구분하지? 🔘 회원 등록 / members/{id} ->어떻게 구분하지? 🔘 회원 수정 / members/{id} ->어떻..
-
http3:http 2022. 6. 14. 23:30
HTTP (Hyper Text Transfer Protocol) : HTTP 메시지에 모든 것을 전송! -HTML, TEXT -IMAGE, 음성, 영상, 파일 -JSON, XML (API) -거의 모든 형태의 데이터 전송 가능 -서버간에 데이터를 주고 받을 때도 대부분 HTTP 사용 HTTP/1.1 1997년 : 가장 많이 사용, 가장 중요한 버전! 기반 프로토콜 -TCP기반 (데이터 많, 속도 느림) : HTTP/1.1, HTTP/2 -UDP기반 : HTTP/3 -현재 HTTP/1.1 주로 사용 -HTTP/2, HTTP/3도 점점 증가 => 확인은 개발자도구/네트워크/protocol HTTP 특징 -클라이언트 서버 구조 -무상태 프로토콜(스테이스리스), 비연결성 -HTTP 메시지 -단순함, 확장 가능 ..
-
http2:http 2022. 6. 13. 19:08
URI와 웹 브라우저 요청 흐름 🌲URI (Uniform Resource Identifier) : URI는 로케이터(locator)(위치로 기억), 이름(name) 또는 둘다 추가로 분류될 수 있다. URl URN -> 찾기 어려워! -> 있다는것만 알아둬 Uniform : 리소스 식별하는 통일된 방식 Resource : 자원, URI로 식별할 수 있는 모든 것(제한 없음) Identifier : 다른 항목과 구분하는데 필요한 정보 URL - Locator : 리소스가 있는 위치를 지정 URN - Name : 리소스에 이름을 부여 위치는 변할 수 있지만 이름은 안변해! urn:isbn:9078908979 (어떤 책의 isbn URN) URN 이름만으로 실제 리소스를 찾을 수 있는 방법이 보편화 되지 않음..
-
http1:http 2022. 6. 11. 17:14
IP (인터넷 프로토콜) -지정한 IP주소 ( IP Address)에 데이터 전달 -패킷(Packet)이라는 통신 단위로 데이터 전달 -패킷 : 출발지 IP, 목적지 IP, 메세지 등을 가지고 클라이언트가 - 패킷을 -> 인터넷에 보내면 인터넷망에서 목적지 IP에 도달하도록 노드를 타고타고 가서 도착한다. IP 포로토콜의 한계 1. 비연결성 : 패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷이 전송됨 (그냥 던지는거) 2. 비신뢰성 : 중간에 패킷이 사라질수도.. 순서대로 안올수도.. 3. 프로그램 구분 : 같은 IP를 사용하는 서버에서 통신하는 애플리케이션이 둘 이상일수도.. => 해결은 TCP! : IP프로토콜의 문제점인 패킷소실과 순서꼬임을 해결함 🌵인터넷 프로토콜 스택의 4계층 1.애플리케이..