HTTP
클라이언트와 서버 사이에 이루어지는 요청 및 응답 프로토콜이다. URL을 통해 정보를 요청하면 요청한 정보를 다시 전달해준다.
주로 웹 환경에서 사용 되는 프로토콜로, IOT 등에는 적합하지 않다.
API (Application Programming Interface)
다른 애플리케이션에서 사용할 수 있도록, 특정 환경의 기능을 제어할 수 있게 만든 인터페이스이다. 우리가 흔히 접하는 구글지도API 등은 구글지도의 기능을 다른 애플리케이션에서 제어할 수 있게 만든 인터페이스라고 쉽게 생각할 수 있다.
REST API (Representational State Transfer)
HTTP의 장점을 최대한 활용하기 위해 고안된 REST 아키텍쳐 스타일을 따르는 API이다. 클라이언트와 서버를 명확하게 구분할 수 있으며 서버에서 특별한 상태를 저장할 필요가 없다. 즉, 서버에서는 들어오는 요청을 단순히 처리하면 되고 클라이언트에서는 정해진 규격에 따라 요청만 하면 된다. 또, HTTP에서 사용하는 Cache를 사용하여 응답을 저장해 불필요한 재 요청을 방지할 수 있다.
REST API와 HTTP API (즉, 웹 API)는 거의 같은 의미로 사용되고 있지만 실제로는 아래의 4가지 원칙이 지켜져야한다.
- 자원의 식별
- 메세지를 통한 리소스 조작
- 자기 서술적 메시지
- 애플리케이션 상태에 대한 엔진으로서 하이퍼미디어(HATEOAS)
Method
크게 아래의 4가지 method가 있다.
- GET (데이터 요청)
- POST (새로운 데이터 생성)
- PUT (데이터 update)
- DELETE (데이터 삭제)
추가로 Patch를 Put 대신 사용하기도 하는데, Put은 데이터가 존재하지 않으면 데이터를 생성하고, Patch는 데이터를 업데이트 하기만 한다. 따라서, Put은 데이터의 모든 요소를 클라이언트가 전송해야하며 Patch는 수정할 요소와 index만 클라이언트가 가지고 있으면 된다.
다시 말해 Patch는 데이터를 부분적으로 변경하고, Put은 데이터 전체를 변경한다. 그러나 하나의 규약일 뿐이지 꼭 지킬 필요는 없다.
Convention
1. URL Router에는 Action(or State)에 대한 정의는 들어가서는 안되며, Resoure는 명사로 표현한다.
GET /user/get/:id (X)
GET /user/:id (O)
2. 특정 Resource의 하위에 존재하는 요소
/Resource/ID/Element
GET /user/:id/files
/Resource/Sub/Element
GET /user/:id/favorite/artists
3. 밑줄 대신 하이픈(_)을 주로 사용하고 소문자를 사용한다.
Request
API를 제어하기 위해 Request 객체에 보다 상세한 정보를 담는다.
- Param (Router에서 :id의 형태로 표현되는 부분)
GET /user/:id/info
localhost:3021/user/3412/info- Query (주로 GET에서 자세한 요청을 전송할 때 사용)
GET /artist/list
localhost:3021/artist/list?genre=rock&country=kr- Body (JSON 형태로 Query와 다르게 URL에는 보이지 않음)
POST /user/signup
localhost:3021/user/signup
Request payload
{
id : pitterpark
pw : 1234
}
일반적으로는 Get, Delete에는 Body를 넘겨주는 것 자체가 불가능하다.