공부기록용

HTTP API 설계 🔴HTTP API - 컬렉션 🔴HTTP API - 스토어 🔴HTML FORM 사용 POST 기반으로의 데이터 등록 회원 목록 /members -> GET 회원 등록 /members -> POST 회원 조회 /members/{id} -> GET 회원 수정 /members/{id} -> PATCH(부분 수정시 용이_주로 사용), PUT(전체 내용을 수정시 용이), POST(PATCH, PUT 모두의 사용이 애매할 때) 회원 삭제 /members/{id} -> DELETE 클라이언트는 등록될 리소스의 URI를 모른다. 회원 등록 /members -> POST POST /members ------ 등록 데이터를 보낸뒤 보낸 데이터의 고유 값을 모른다는 의미이다. 즉, A와 B의 정보에 C라..

클라이언트 ➡️ 서버로의 데이터 전송 전달 방식 쿼리 파라미터를 통한 데이터 전송 GET 주로 정렬 필터를 쓸 때 많이 사용(검색어를 치거나 게시판 리스트에 정렬 조건을 넣을 때) 메시지 바디를 통한 데이터 전송 POST, PUT, PATCH 회원 가입, 상품 주문, 리소스 등록, 리소스 변경 전달 상황 정적 데이터 조회 할 때_이미지, 정적 텍스트 문서 쿼리 파라미터 미사용 조회는 GET를 사용 일반적으로 쿼리 파라미터 없이 리소스 경로로 단순하게 조회 가능 동적 데이터 조회 할 때_주로 검색, 게시판 목록에서 정렬 혹은 필터(검색어) 쿼리 파라미터 사용 조회는 GET 사용 조회 조건을 줄여주는 필터와 조회 결과를 정렬하는 정렬 조건에 주로 사용 GET은 쿼리 파라미터 사용해서 데이터를 전달 GET메소..

HTTP 메소드 API URI 설계 시, 리소스 식별, URI 계층 구조 활용 URI는 리소스만 식별 리소스와 해당 리소스를 대상으로 하는 행위을 분리, 리소스는 명사, 행위는 동사 HTTP 메소드 종류 GET: 리소스 조회 POST: 요청 데이터 처리, 주로 등록에 사용 PUT: 리소스를 대체, 해당 리소스가 없으면 생성 PATCH: 리소스 부분 변경 DELETE: 리소스 삭제 HEAD: GET과 동일하지만 메시지 부분을 제외하고, 상태 줄과 헤더만 반환 OPTIONS: 대상 리소스에 대한 통신 가능 옵션(메서드)을 설명(주로 CORS에서 사용) CONNECT: 대상 리소스로 식별되는 서버에 대한 터널을 설정 TRACE: 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행 GET 리소스 조회 ..

🔴HTTP 특징 🔴Stateful, Stateless 차이 🔴HTTP 메시지 🔻시작라인 🔻HTTP 헤더 🔻HTTP 메시지 바디 HTTP(HyperText Transfer Protocol) HTTP 메시지에 모든 것을 전송 HTML, TEXT IMAGE, 음성, 영상, 파일 JSON, XML (API) 거의 모든 형태의 데이터 전송 가능 서버간에 데이터를 주고 받을 때도 대부분 HTTP 사용 기반 프로코톨 TCP: HTTP/1.1, HTTP/2 UDP: HTTP/3 현재 HTTP/1.1 주로 사용 HTTP 특징 클라이언트 서버 구조 무상태 프로토콜(스테이스리스), 비연결성 HTTP 메시지를 통해서 통신 단순함, 확장 가능 클라이언트 서버 구조 Request Response 구조 클라이언트는 서버에 요청을 ..

인터넷 통신 🔴 IP 🔴 TCP/URP 🔴 DNS 🔴 URI(URL/URN) 🔻 URI문법 IP(인터넷 프로토콜) 클라이언트와 서버에 각각 IP주소가 부여되고 그 주소로 보낸다 IP (인터넷 프로토콜)의 역할 지정한 IP주소에 데이터 전달 패킷(Packet)_규칙이라는 통신 단위로 데이터 전달 IP패킷에는 출발지IP, 목적지IP를 담아 간다는걸 우선 생각(다른것도 있음) IP 프로토콜의 한계 비연결성(패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷을 전송한다.) 비신뢰성(중간에 페킷이 사라지거나 순서대로 보낸 패킷이 그 순서대로 오지 않을 수 있다.) 프로그램 구분(같은 IP를 사용하는 서버에서 통신하는 애플리케이션이 둘 이상일 경우(노래듣고, 영상보고 하는 경우) 구분하는데 한계가 있다.) TCP..