# 1. representational State transfer
웹상에서 사용되는 여러 리소스를 HTTP URI로 표현하고 리소스에대한 행위를 HTTP Method로 정의하는 방식이다 즉 리소스(HTTP URI로 정의된)를 어떻게 한다(HTTP Method+ Payload)를 구조적으로 깔끔하게 표현

• 장점 : sel-descriptiveness, RESTful API는 그 자체만으로도 API의 목적이 쉽게 이해 된다.
• 단점 : 표준규약이 없어, 안티 패턴으로 작성되는 경우가 흔하다

2. RESTful API 설계규칙

• URI 정보를 명확하게 표현해야 한다.
  resource는 명사를 사용한다
• resource에 대한 행위를 HTTP Method(GET, POST, PUT, DELETE)로 표현한다.
  URI에 HTTP Method가 포함되서는 안된다.
  URI에 동사가 포함되서는 안된다.
• resource 사이에 연관 관계가 있는 경우
  /리소스/고유ID/관계 있는 리소스
• 파일의 경우 payload의 포맷을 나타내기 위한 파일 확장자를 URI에 포함시키지 않는다.
• URI는 / 구분자를 사용하여 자원의 계층 관계를 나타내는데 사용한다
• URI 마지막 문자로 /를 포함하지 않는다.
• 불가피하게 URI가 길어지는 경우-을 사용하여 가독성을 높인다.
• _는 사용하지 않는다. URI 경로에는 대문자를 사용을 피하도록 규정하고 있다.

3.Query Parameters

웹 페이지의 url 주소를 자세히 보면 종종 ? 가 포함되어 있는 것이 있다. 물음표 뒤에는 늘 key=value 형식의 문자열이 따라옵니다. 이를 Query parameter 라고 부른다.
주로 데이터를 조건으로 거르거나(filtering), 특정 방식으로 정렬하거나(sorting), 검색(searching)하고자 하는 경우에 활용된다.

4. Path Parameters

Query Parameters 와 유사해보이지만 그 역할이 완전히 다른 Path parameter도 있습니다.
해당 리소스에 더 자세한 정보를 얻기 위해 접근할 때 사용합니다.