HTTP API - 컬렉션 POST 기반 등록 예) 회원 관리 API 제공 HTTP API - 스토어 PUT 기반 등록 예) 정적 컨텐츠 관리, 원격 파일 관리 HTML FORM 사용 웹 페이지 회원 관리 GET, POST만 지원 (제약) 회원 관리 시스템 API 설계 - POST 기반 등록 회원 목록 조회 : /members -> GET 회원 등록 : /members -> POST 회원 조회 : /members/{id} -> GET 회원 수정 : /members/{id} -> PATCH(부분 변경), PUT(게시글 덮어쓰기), POST 회원 삭제 : /members/{id} -> DELETE POST - 신규 자원 등록 특징 클라이언트는 등록될 리소스의 URI를 모른다. 회원 등록 /members ->..
데이터 전달 방식 쿼리 파라미터를 통한 데이터 전송 GET 주로 정렬 필터 (검색어) 메시지 바디를 통한 데이터 전송 POST, PUT, PATCH 회원가입, 상품 주문, 리소스 등록, 리소스 변경 4가지 상황 정적 데이터 조회 (GET) 이미지, 정적 텍스트 문서 쿼리 파라미터 없이 리소스 경로로 단순하게 조회 가능 동적 데이터 조회 (GET) 주로 검색, 게시판 목록에서 정렬 필터 (검색어) 조회 조건을 줄여주는 필터, 조회 결과를 정렬하는 정렬 조건에 주로 사용 GET은 쿼리 파라미터를 사용해서 데이터를 전달 HTML Form을 통한 데이터 전송 회원 가입, 상품 주문, 데이터 변경 POST-저장 HTML form 태그 Content-Type : application/x-www-form-urlenc..
안전 (Safe Methods) 호출해도 리소스를 변경하지 않는다. 안전한 메소드 = GET, HEAD, OPTIONS, TRACE 안전하지 않은 메소드 = POST, PUT, DELETE, CONNECT, PATCH 멱등 (Idempotent Methods) f(f(x)) = f(x) 1번 호출하든, 2번 호출하든, 100번 호출하든 결과가 똑같다. 멱등 메서드 GET : 1번 조회하든, 2번 조회하든 같은 결과가 조회된다. PUT : 결과를 대체한다. 같은 요청을 여러번 해도 최종 결과는 같다. DELETE : 결과를 삭제한다. 같은 요청을 여러번 해도 삭제된 결과는 같다. POST = 멱등이 아니다! 2번 호출하면 같은 결제가 중복해서 발생할 수 있다. 활용 자동 복구 메커니즘 서버가 TIMEOUT..
HTTP API를 만들어보자 요구사항 회원 정보 관리 API를 만들어라 조회 회원 목록 조회 회원 조회 등록 회원 등록 수정 회원 수정 삭제 회원 삭제 API URI 설계 Uniformed Resource Indentifier 회원 목록 조회 (read-member-list) 회원 조회 (read-member-by-id) 회원 등록 (create-member) 회원 수정 (update-member) 회원 삭제 (delete-member) 가장 중요한 것은 리소스 식별 리소스의 의미 회원을 등록하고 수정하고 조회하는게 리소스가 아니다. 회원이라는 개념 자체가 리소스다. 리소스를 어떻게 식별하는게 좋을까? 회원이라는 리소스만 식별하면 된다. 회원 리소스를 URI에 매핑 리소스 식별, URI 계층 구조 활용 ..
HTTP 메시지 구조 start-line : 시작 라인 header : 헤더 empty line (CRLF) : 공백 라인 message body HTTP 요청 메시지 start-line GET /search?q=hello&hl=ko HTTP/1.1 header Host: www.google.com 요청 메시지도 body 본문을 가질 수 있음 HTTP 응답 메시지 start-line HTTP/1.1 200 OK header Content-Type: text/html;charset=UTF-8 Content-Length: 3423 CRLF message body ... Start Line 요청 메시지 start-line = request-line request-line = method SP(공백) reque..
HTTP ( HyperText Transfer Protocol) 거의 모든 형태 데이터를 HTTP 메시지에 담아서 전송한다. HTML, TEXT IMAGE, 음성, 영상, 파일 JSON, XML (API) 서버간에 데이터를 주고 받을 때도 대부분 HTTP 사용 HTTP 역사 HTTP/0.9 : GET 메서드만 지원, HTTP 헤더 없음 HTTP/1.0 : 메서드, 헤더 추가 HTTP/1.1 : 가장 많이 사용 RFC2068(1997) -> RFC2616(1999) -> RFC7230~7235(2014) HTTP/2 : 성능 개선 HTTP/3 : TCP 대신에 UDP 사용, 성능 개선 기반 프로토콜 TCP : HTTP/1.1. HTTP/2 UDP : HTTP/3 느린 TCP 대신 UDP 프로토콜 위에 애플..
DNS 조회 www.google.com:443 ip : 200.200.200.2 HTTP 요청 메시지 생성 HTTP 요청 메시지 웹 브라우저가 HTTP 메시지 생성 SOCKET 라이브러리를 통해 전달 A : TCP/IP 연결 (IP, PORT) B : 데이터 전달 TCP/IP 패킷 생성, HTTP 메시지 포함 패킷 생성 TCP/IP 패킷 출발지 IP, PORT 목적지 IP, PORT HTTP 메시지 search : 검색 query parameter HTTP 응답 메시지
URI : Uniform Resource Identifier Uniform : 리소스를 식별하는 통일된 방식 Resource : 자원, URI로 식별할 수 있는 모든 것 (제한 없음) Identifier : 다른 항목과 구분하는데 필요한 정보 URL (Locator) : 리소스가 있는 위치를 지정 URN (Name) : 리소스에 이름을 부여 URN 이름만으로 실제 리소스를 찾을 수 있는 방법이 보편화 되지 않음. URI는 locator, name 또는 둘 다 추가로 분류될 수 있다. URL : Resource Locator 리소스의 위치 URN : Resource Name 리소스의 이름 URL (전체 문법) Scheme://[userinfo@]host[:port][/path][?query][#fragme..
https://github.com/gyoogle/tech-interview-for-developer GitHub - gyoogle/tech-interview-for-developer: 👶🏻 신입 개발자 전공 지식 & 기술 면접 백과사전 📖 👶🏻 신입 개발자 전공 지식 & 기술 면접 백과사전 📖. Contribute to gyoogle/tech-interview-for-developer development by creating an account on GitHub. github.com https://github.com/hongcheol/CS-study/tree/main/Algorithm#이진-탐색트리- GitHub - hongcheol/CS-study: cs지식을 정리하는 공간 cs지식을 정리하는 공간...
