개발자되기 프로젝트

1. HTTP 상태 코드 클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능 1XX(Informational) : 요청이 수신되어 처리 중~ 2XX(Successful) : 요청 정상 처리 3XX(Redirection) : 요청을 완료려면 추가 행동이 필요 4XX(Client Error) : 클라이언트 오류, 잘못된 문법 등으로 서버가 요청을 수행할 수 없음 클라이언트가 범인 5XX(Server Error) : 서버 오류, 서버가 정상 요청을 처리하지 못함. 서버가 범인 2. "만약 모르는 상태 코드가 나타나면..?" 클라이언트가 인식할 수 없는 상태코드를 서버가 반환하면...?어떻게 이해함..? 클라이언트는 상위 상태코드로 해석해서 처리 299 뭔데??? --> 2xx 처리 451 뭐고??? ..

HTTP API - 컬렉션 - POST 기반 등록 - 회원 관리 API 제공 HTTP API - 스토어 - PUT 기반 등록 - 정적 컨텐츠 관리, 원격 파일 관리 HTML FORM 사용 - 웹 페이지 회원 관리 - GET, POST만 지원 1. 회원 관리 시스템 API 설계 - POST 기반 등록 회원 목록 /members -> GET 회원 등록 /members -> POST 회원 조회 /members/{id} -> GET 회원 수정 /members/{id} -> PATCH, PUT, POST 회원 삭제 /members/{id} -> DELETE 2. POST 기반 등록 클라이언트는 등록될 리소스의 URI를 몰라!!!! - 클라이언트는 데이터만 줌 ㅋㅋ - 회원 등록 / members -> POST -..

1. 클라이언트에서 서버로 데이터 전달 방식 Query Parameter를 통한 데이터 전송 - GET - 정렬 필터(검색어) 메시지 바디를 통한 데이터 전송 - POST, PUT, PATCH - 회원 가입, 상품 주문, 리소스 등록 및 변경 2. 서버로 데이터 전송하는 4 가지 상황 정적 데이터 조회 - 이미지, 정적 텍스트 문서 동적 데이터 조회 - 검색, 게시판 목록에서 정렬 필터(검색어) HTML Form을 통한 데이터 전송 - 회원 가입, 상품 주문, 데이터 변경 HTTP API를 통한 데이터 전송 - 회원 가입, 상품 주문, 데이터 변경 - 서버 to 서버, 앱 클라이언트, 웹 클라이언트(Ajax) 3. 정적 데이터 조회 쿼리 파라미터 미사용 이미지 정적 텍스트 문서 일반적으로 GET사용 정적..

안전, Safe Methods 멱등, Idempotent Methods 캐시가능, Cachable Methods 1. 안전(Safe) 호출해도 리소스를 변경하지 않는다. GET 2. 멱등(Idempotent) 한 번 호출하든 여러 번 호출하든 결과가 똑같다 GET : 항상 같은 겨로가가 조회됨. PUT : 결과를 대체함. 같은 요청을 여러 번 해도 결과는 같음. DELETE : 결과를 삭제함. 여러 번 요청해도 삭제된 결과는 같음. POST : 멱등이 아님!@!!!! 만약 두 번 호출하면 프로세스가 두 번 호출되어 결제가 두 번 될 수 있음 ㅋㅋㅋ 활용 - 자동 복구 메커니즘 - 서버가 TIMEOUT등으로 정상 응답을 못줄 때, 클라이언트가 같은 요청을 다시 해도 되는가..? - 멱등한 METHOD는 이..

1. 주요 HTTP 메서드 GET : 리소스 조회 POST : 요청 데이터 처리, 주로 등록에 사용 PUT : 보내는 리소스로 기존 리소스를 대체, 해당 리소스가 없으면 생성 PATCH : 리소스 부분 변경 DELETE : 리소스 삭제 2. 기타 메서드 HEAD : GET과 동일하지만 메시지 부분을 제외하고, 상태 줄과 헤더만 반환 OPTIONS : 대상 리소스에 대한 통신 가능옵션을 설명(CROS에서 사용) CONNECT : 대상 자원으로 식별되는 서버에 대한 터널을 설정..? 안씀 TRACE : 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행..? 안씀 3. GET 리소스 조회 리소스 가져와! 서버에 전달하고 싶은 데이터는 query(query parameter, query string)..

1. 요구사항 회원 목록 조회 회원 조회 회원 등록 회원 수정 회원 삭제 2. API URI설계 URI 설계시 가장 중요한 것 : 리소스 식별 리소스의 의미는 뭘까.? - 회원을 등록하고 수정하고 조회하는 것은.. 리소스가 아니야! - "회원"이라는 개념이 바로 리소스! 그럼 리소스(회원)을 어떻게 식별할까? - 회원을 등록하고 수정하고 조회하는 것을 모두 배제하자. - 그냥 회원이라는 리소스만 식별하자! - 즉 회원 리소스를 URI에 맵핑하자. 위에 내용에 따라 설계해보자.. 회원 목록 조회 /members 회원 조회 /member/{id} -> 어떻게 구분하지..? 회원 등록 /member/{id} -> 어떻게 구분하지..? 회원 수정 /member/{id} -> 어떻게 구분하지..? 회원 삭제 /m..

1. HTTP 메시지 구조 HTTP 요청 메시지 구조 - 요청 메시지도 body 본문 가질 수 있음 HTTP 응답 메시지 공식 스펙 : RFC7230 2. 시작 라인 start-line = request-line(요청 메시지), status-line(응답 메시지) 로 구성되어있음. 요청 메시지 request-line = method SP(공백) request-target SP HTTP-version CRLF(엔터) HTTP 메서드 - GET, POST, DELETE, PUT.. - 서버가 수행해야 할 동작 지정 - GET : 리소스 조회, POST: 요청 내역 처리 요청 대상, Request-target - absolute-path[?query] (절대경로[?쿼리]) - 절대경로 = '/'로 시작하는 경..

1. 비 연결성 HTTP는 기본이 연결을 유지하지 않는 모델. 일반적으로 초 단위 이하의 빠른 속도로 응답 필요한 데이터 주고받고 연결 끊어버림 1시간 동안 수 천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 매우 적음 서버 자원을 효율적으로 사용할 수 있음. 2. 한계와 극복 TCP/IP 연결을 새로 맺어야함. 3 way handshake 시간 필요.. 웹 브라우저로 사이트를 요청하면 html, js, css, img, 등등 많은 자원이 함꼐 다운됨. 지금은 HTTP 지속 연결(Persistent Connections)로 문제 해결함. - 연결 - 요청/HTML응답 - 요청/자바스크립트 응답 - 요청/이미지 응답 - 종료 3. Stateless를 기억.. 딱 같은 시간에 맞춰 발생하는 대..