Request Method

U(niform)R(esource)L(ocator) : 특정한 리소스의 경로를 나타냄 : 리소스가 어디에있는지 고유한값을 나타내는 주소

• URL의 구성 : protocal, hostname(어떤 서버에 접속하는지), 서버의 어떤 어플리케이션(어떤포트)에 접근할건지(보통 웹사이트로 이용되는 포트는 생략가능), pathname(어떤 경로에 접근할건지) , query
  • https://www.server.com/index.html
  • https://www.server.com/courses/backend/search?q=love

Request method : url와 함께사용하는, url로 나타내는 클라이언트가 접근하고자하는 리소스를 이용해 어떤 action을 원하는지를 명시

• 종류 : HTTP Request Method 종류 : https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods 한국어 버전 : https://developer.mozilla.org/ko/docs/Web/HTTP/Methods
  • GET : get
  • POST : create
  • PUT : replace : 기존 url date update
  • DELETE : delete
  • PATCH : replace partially : 부분적 update
  • HEAD : get without body : data는 받지 않고 head만 받고싶을때
  • OPTIONS : all supported methods for URL : 해당 url에서 사용가능한 모든 request options 알고싶을때
  • TRACE : echoes the received request : 서버가 살아있는지, 내 요청에 대한 반응을 확인
  • 서버에있는 데이터를 읽기만하고 변경하지 않는 요청
  • 서버에 있는데이터를 변경하는 요청

request method-HTTP Status code 로 다양한 상황을 나타낼수있음

진정한 Restful API 도대체 뭘까?

클라이언트입장에서 A(pplication)P(rogramming)I(nterface): API는 어플리케이션만을 말하는게 아니라 사용하는 사람들이 쉽게 쓸수있는 인터페이스(쉽게 생각하면 함수라고 생각해도 됨)

서버 입장에서 API : 클라이언트가 사용가능한 URL같은 것(클라이언트가 쓰기편한 인터페이스니까)

RESTful : (~ful : ~이 가득한, ~의 성격을 지닌) REST 성격을 지닌

RE(presentational)S(tate)T(ransfer) : 대표하는 상태를 전송 : 일종의 Software(서버) Architectural Style → REST한 웹서비스를 만들때 지켜야하는 가이드라인이 존재

• 대표하는 상태를 전송하는 구조란?

  : 서버에 다양한 데이터가 존재할때 이 데이터를 그룹지어 관련데이터는 url형태로 클라이언트에 제공될때, →클라이언트는 서버에서 제공하는 url 중에서 원하는 것을 골라 요청 → 서버는 클라이언트가 요청한 데이터의 상태를 클라이언트에 보냄

  • 이때 representational(대표됨)의 범위 : 클라이언트가 요청한 데이터 타입까지 포함 ex. client : data B 를 json 으로 보내주라, server : data B state를 json으로 변환해(대표해) 보냄
  • 이때 state 범위 : 하나의 데이터의 상태뿐만아니라 서버에서 이용가능한 모든 url의 상태도 의미할수있음

  : 간단하게말하면 : http method 4(기본동작인 CRUD-GET,POST….)개를 이용해 url를 디자인하는것(api를 디자인하는것)

RESTful System 6 guiding constrains : RESTful System의 6가지 조건