URL

• URL (Uniform Resource Locator)
  서버에 요청을 할 때 어떤 리소스를 원하는지에 대해 나타내야 한다. 이때 사용하는 것이 바로 URL이다. URL은 마치 고유한 주소같은 것이다.

🙄 https://www.server.com/index.html 자세히 보기

• https: 어떤 protocol인지를 나타냄
• www.server.com: hostname으로, 어떤 서버에 접속하는지를 나타냄
• /: 해당 서버 속 어떤 포트에 접속할 건지를 나타낼 수 있음. 그러나 보통 웹사이트에 나타내는 건 생략이 가능함
• index.html: path로, 어떤 경로에 접속할 것인지 나타낼 수 있음

위의 부분을 토대로 다음의 예시를 분해해보자.

• https://www.server.com/board/front/search?q=node
  • https: protocol
  • www.server.com: server
  • board/front/serch: path
  • q=node: query(검색 결과)

URL을 이용하면 서버에게 무엇을 원하는지를 나타낼 수 있다. 여기서 request method까지 이용하면 해당 리소스를 이용해서 어떤 액션을 원하는지 명시할 수 있다.

Request method

HTTP는 request method를 정의하여 주어진 리소스에서 수행하기를 원하는 액션을 나타낸다. 각각의 메서드는 서로 다른 의미를 구현하지만, 일부 기능은 서로 공유하기도 한다.

request method의 종류

request method	설명	서버 데이터 변경여부
GET	특정 리소스를 검색하고 반환받기 위해 씀. 원하는 정보를 서버에 요청할 때 사용함	X
HEAD	서버의 각종 정보 확인을 위해 씀. GET과 동일하지만 request body가 없음	X
POST	요청된 자원(리소스)을 생성하기 위해 씀. POST로 정보 전송 시, URL에 파라미터가 드러나지 않아 데이터 전송 시 쓰임	O
PUT	요청된 자원을 수정하기 위해 씀.	O
DELETE	요청한 자원을 삭제할 때 씀. 그러나 client에서 server의 자원을 삭제할 수 있도록 허가하는 것은 매우 위험하기에 거의 쓰지 않음.	O
CONNECT	프록시 기능을 요청할 때 사용함	O
OPTIONS	웹서버에서 지원하는 메소드를 알기위해 씀	X
TRACE	목적 리소스의 경로를 따라 loop-back 메시지를 호출하기 위해 테스트용으로 쓰임	X
PATCH	요청된 자원(리소스)을 수정하기 위해 씀. 단, PUT과 달리 자원의 일부만 수정함	O

각각의 request method의 기능

• request body(요청에 바디 존재): 요청에 body(데이터)가 존재하는가?
• response body(응답에 바디 존재): 응답에 body(데이터)가 존재하는가?
• safety(안정성, 데이터 변경에 여부와 같음): 여러번 요청해도 서버에 있는 데이터를 변경하지 않는가? (변경하지 않으면 안전하다고 간주함)
• Idempotent: 동일한 요청을 여러번 해도 항상 서버를 동일한 상태로 유지할 수 있는가?
• cache(캐시기능)

🤔 HEAD나 POST
: POST는 서버에 데이터를 만드므로 데이터를 변경하니 안전하지 않고, 포스트를 여러번 요청하면 여러번 생성될 수 있으므로 멱등성이 no이다. 생성하는 것도 부분적으로만 캐시가 가능하다.

🙄 PUT과 PATCH
: PUT은 원하는 URL에 데이터를 전체적으로 업데이트하는 것이다. 때문에 아무리 많이 요청해도 동일한 URL에 동일한 내용으로 계속 업데이트되어 멱등성이 yes인 것이다. 다만 서버 데이터를 계속 변경하진 않으니 안전하진 않음. 그러나 부분적으로 업데이트 가능한 PATCH는 멱등성이 No이다. 서버의 구현 방식에 따라 다르겠지만 만약 부분적으로 업데이트한 내용을 추가하는 업데이트 하는 서버의 기능이라면 부부적으로 계속 추가가 되므로, 그런 경우 멱등성이 YES이다.

표로 보는 HTTP method