[꼼꼼한 개발자] 꼼코더

👨🏻‍🏭 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로 ..

2️⃣ 2xx (Successful) 클라이언트의 요청을 성공적으로 처리 200 OK 201 Created 202 Accepted 204 No Content 👌🏻 200 OK 요청 성공 (GET과 같은 조회 요청에 성공적으로 응답하는 경우) 클라이언트가 서버에 GET으로 리소스를 요청함 서버가 리소스를 조회함 Stauts code: 200 과 리소스를 HTTP 응답 메시지를 만들어 클라이언트에 보냄 👨🏻‍🏭 201 Created 요청 성공 후 새로운 리소스 생성됨(POST와 같은 생성요청으로 리소스가 생성이 정상적으로 된 경우) 클라이언트가 서버에 POST로 신규 자원을 등록 요청함 서버가 리소스를 생성하고 리소스의 URI를 관리함 Stauts code: 201, Location: 생성된 리소스의 URI..

🔖 상태 코드 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..

🧑🏻‍🏫 데이터 전달 방식 데이터 전달 방식은 크게 2가지 경우로 나뉜다. 1) 쿼리 파라미터를 통한 데이터 전 주로 GET 방식으로 많이 사용 검색어로 검색할 때, 게시판 리스트에 정렬 조건을 넣을 때 쿼리 파라미터를 이용해서 많이 사용. 2) 메시지 바디를 통한 데이터 전송 POST, PUT, PATCH 회원 가입, 상품 주문, 리소스 등록, 리소스 변경 클라이언트에서 서버로 전송할 때 HTTP 메시지 바디를 통해서 데이터를 전송한다. POST, PUT, PATCH 방식으로 주로 사용한다. 회원가입을 하려면 클라이언트에서 데이터를 서버로 전송하기 때문에 회원 가입, 상품 주문, 리소스 등록, 리소스 변경할 때 사용한다. 🍀 4가지 상황 1) 정적 데이터 조회 이미지, 정적 텍스트 문서 2) 동적 데이..

🌈 HTTP 메서드의 속성 1) 안전(Safe Methods) 2) 멱등(Idempotent Methods) 3) 캐시가능(Cacheable Methods) 👷🏻 안전(Safe) 호출해도 리소스가 변경되지 않는다. GET, OPTIONS, TRACE등은 조회의 성격을 가지고 있기에 리소스를 변경하지 않고, 그렇기에 안전하다. 이 때, 안전의 범위는 해당 리소스에만 해당되며 그 외적인 요소는 고려하지 않는다. 리소스 호출시마다 로그가 남는다 하여도 이는 리소스에 대한 영향은 아니기 때문에 고려하지 않는다. 📌 안전 메서드 종류 1) 안전O: GET, HEAD 2) 안전X: POST, PUT, PATCH, DELETE Q. 계속 호출하면, 로그 같은 것이 쌓여서 장애가 발생할 수도 있지 않은가? A. 안전은..

📝 PUT 리소스 대체 리소스가 있으면 대체(덮어씀) 리소스가 없으면 생성 (중요!) 클라이언트가 리소스를 식별 클라이언트가 리소스 위치를 알고 URI 지정(POST와 차이점) POST) /members :→ 클라이언트는 리소스 위치 모름 PUT) /members/100 → 클라이언트는 리소스 위치 알고 URI 지정 💁🏻‍♂️ PUT 동작 과정 PUT은 리소스가 있으면 대체하는 경우, 없으면 생성하는 2가지 경우가 존재한다. 1) 리소스 대체 1 - 메시지 전달 클라이언트가 /members/100에 리소스를 대체하기 위해 PUT 방식으로 HTTP 요청 메시지를 서버에 보낸다. 2) 리소스 대체 2 - 리소스 대체 서버에 /members/100 이 있으면, HTTP 요청 메시지의 message-body에 ..

📑 HTTP 메서드 종류 GET : 리소스를 조회 POST : 요청 데이터를 담아서 처리 PUT : 리소스를 대체 *해당 리소스가 없으면 생성 PATCH : 리소스 부분 변경 DELETE : 리소스 삭제 HEAD : GET과 동일하지만 메시지 부분을 제외하고 상태 줄과 헤더만 반환 OPTIONS : 대상 리소스에 대한 통신 가능 옵션(메서드)를 설명 (주로 CORS에서 사용) TRACE : 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행 GET과 POST는 클라이언트가 서버에 뭔가 요청을 할 때 기대하는 행동이다. 🔎 GET 리소스를 조회한다. 서버에 전달하고 싶은 데이터는 쿼리 파라미터 또는 쿼리 스트링을 통해서 전달한다. GET은 메시지 바디를 전달할 수 있지만 실무에서는 바디에 보통 데..