요청(req)과 응답(res), http 메서드

📍 요청과 응답

• request: 유저/클라이언트가 서버에 보내는 '요청'
• response: 서버로부터 유저/클라이언트가 받는 '응답'

요청과 응답은 표준화된 소통방식(프로토콜)을 통해 이루어진다. 그 표준화된 소통방식에는 유효한 요청의 형태, 어떤 데이터가 전송되어야하는지 등이 정해져있다.

헤더

요청과 응답은 모두 헤더를 지니고 있다. 헤더란 요청과 응답에 첨부되는 메타 정보이다.

ex)

• 요청이 보내지는 호스트(localhost:3000)
• 응답 데이터 캐시 방법
• 요청에 사용되는 브라우저
• 받는 응답유형(html, xml)
• 쿠키
• 사용된 http 버전

📍 http

http란 Hyper Text Transfer Protocol로 위에 말한 요청과 응답이 수행되는 표준화된 소통방식 중 하나이다.

http에는 메서드가 있는데 http메서드는 클라이언트가 서버에게 수행하길 원하는 동작을 나타낸다. 그러므로 주로 클라이언트에서 서버로의 요청에서 사용된다. 응답에는 일반적으로 사용되지 않는다.

서버가 클라이언트의 요청에 대해 응답하는 경우는 상태 코드, 헤더, 본문 등의 정보를 포함한다. 응답이기 때문에 어떤 동작을 수행하길 요청하지 않는다.

http 메서드 중 다섯가지가 주요 메서드로써 자주 사용된다.

GET 메서드

• 용도: 리소스를 서버로부터 가져오기 위해 사용된다.
• 동작: 클라이언트는 서버에게 리소스를 요청하고, 서버는 해당 리소스를 응답으로 반환한다.
• 예시: 웹 브라우저에서 웹 페이지에 접속하거나 이미지 파일을 요청할 때 사용된다.
• 특징: GET요청은 주로 데이터를 가져오는 용도로 사용되며, 요청의 본문(body)에 데이터를 포함하지 않는다. 포함해도 어차피 대부분 서버에서 확인을 안 한다. 그러므로 GET요청에 서버에 전달하고 싶은 데이터를 담으려면 query(쿼리 매개변수, 쿼리 문자열)를 사용해야한다.

POST 메서드

• 용도: 서버에 새로운 데이터를 제출하거나 리소스를 생성하기 위해 사용된다.
• 동작: 클라이언트는 서버에게 데이터를 전송하고, 서버는 해당 데이터를 처리하고 새로운 리소스를 생성한다.
• 예시: 로그인 정보를 서버로 제출하거나, 사용자가 양식을 작성한 데이터를 서버로 전송할 때 사용된다.
• 특징: POST요청은 요청의 본문(body)에 데이터를 포함하여 전송하며, 복잡한 데이터 전송에 사용된다.

PUT 메서드

• 용도: 리소스를 업데이트하거나 새로운 리소스를 생성하기 위해 사용된다.
• 동작: 클라이언트는 서버에게 전체 리소스를 제공하고, 서버는 해당 리소스를 업데이트하거나 새로운 리소스를 생성한다.
• 예시: 이미 존재하는 사용자의 정보를 업데이트하거나, 새로운 데이터를 서버에 업로드할 때 사용된다.
• 특징: PUT요청은 전체 리소스를 업데이트하므로 클라이언트는 전체 데이터를 전송해야 한다.

PATCH 메서드

• 용도: 리소스의 부분적인 업데이트를 수행하기 위해 사용된다.
• 동작: 클라이언트는 서버에게 업데이트하고자 하는 리소스의 일부 데이터를 전송하고, 서버는 해당 부분을 업데이트한다.
• 예시: 사용자의 프로필 이미지를 변경하거나, 특정 필드의 값을 수정할 때 사용된다.
• 특징: PATCH요청은 일부 데이터만 전송하여 리소스를 업데이트하므로 PUT요청에 비해 효율적이다.

DELETE 메서드

• 용도: 서버에서 특정 리소스를 삭제하기 위해 사용된다.
• 동작: 클라이언트는 서버에게 삭제하고자 하는 리소스의 식별자를 전송하고, 서버는 해당 리소스를 삭제한다.
• 예시: 사용자 계정을 삭제하거나, 특정 데이터를 서버에서 삭제할 때 사용된다.
• 특징: DELETE요청은 서버에서 특정 리소스를 삭제하도록 요청하며, 본문에 데이터를 포함하지 않는다.

html에서 요청 본문에 데이터를 담는 법

<!-- 버튼을 사용하여 요청할 때 -->
<form action="요청이 전달될 url" method=“http메서드” 
      name="입력 데이터를 할당된 이름을 통해 액세스하는데 사용될 그 이름">
  <button type="submit">버튼</button>
</form>

+) 260712 추가

메소드별 정의를 위한 세가지 축

• Safe(안전): 서버 상태를 안 바꿈. 읽기 전용. → GET, HEAD, OPTIONS
• Idempotent(멱등): 여러 번 보내도 결과가 같음. → GET, PUT, DELETE, HEAD (POST는 아님)
• Body 유무: 요청에 바디를 실음. → POST, PUT, PATCH (GET/DELETE는 원칙상 바디 안 실음)

메소드별 정의

조회라고 무조건 GET은 아니다

GET은 파라미터를 URL에 실음. 근데 검색 조건이 너무 크거나 민감하면 GET이 안 됨:

• 복잡한 검색(수십 개 필터를 body로) → URL 길이 한계 → POST /search
• 민감정보를 body로 보내야 할 때 → URL/로그 노출 방지 → POST

login이 딱 이거. 사실상 "자격증명 검증"이지만 비밀번호를 body에 실어야 해서 GET 불가 → POST.

"읽기면 무조건 GET"이 아니라, 읽기여도 POST일 수 있음.

생성이라고 무조건 POST는 아니다

클라이언트가 리소스의 URI(ID)를 직접 정해서 생성하면 PUT이 맞음:

• POST /users → 서버가 ID 정함 (/users/42 생성). 같은 요청 두 번 = 유저 2명. 비멱등.
• PUT /users/emily → 클라가 URI 지정. 두 번 보내도 emily 하나. 멱등.

즉 "생성"이라도 URI를 누가 정하냐 + 멱등이냐에 따라 PUT일 수 있음.