먼저 API
에 대해서 설명을 하고자 합니다. API
는 위키백과에서 다음과 같의 정의하고 있습니다.
API
는 컴퓨터나 컴퓨터 프로그램 사이의 연결이다. 일종의 소프트웨어 인터페이스이며 다른 종류의 소프트웨어에 서비스를 제공한다.
저도 API를 조사하다가 이 글을 보고 한 번에 와닿지는 않더라고요. 그래서 제가 이해한 바탕으로 다시 정리해보자면 API(Application Programming Interface)
는 프로그램 작성을 위한 데이터나 기능의 집합
입니다. API
는 어디까지 집합에 대한 개념만을 이야기합니다. 그래서 이러한 개념들을 구체화 시켜 구현하게 되면 우리는 그것을 라이브러리라고 부르게 됩니다.
많은 자료들이 API
를 식당 웨이터에 비유해서 이야기하고 있습니다. 고객(사용자)는 음식을 주문하는데, 음식의 조리과정은 궁금하지도 않고 알 필요도 없습니다. 그저 나온 음식(결과)만을 필요로 하죠. 그래서 고객과 주방을 주문을 받고, 서빙을 하는 웨이터가 API
의 모습에 비유할 수 있다라고 예시를 많이 들고 있습니다.
REST
라는 개념을 알고 와야하는데 이 개념은 예전에 소개했으니 링크로 대체하고 넘어가겠습니다. 간단하게 소개만 하자면 REST
는 전송하는 서버 자원에 대한 주소 지정방식입니다. 어떤 자원이 있으면 어떤 방식으로 보낼 건지에 대한 내용을 주소로 나타내어 알기 쉽게 하도록 만드는 것 입니다.
REST API
는 REST
아키텍쳐를 잘 지킬 수 있도록 API
화 시키는 것 입니다. API
화 시킴으로써 한 서비스 내에서 통일된 규칙을 가지고 인터페이스끼리 통신할 수 있게 됩니다.
REST API
를 작성할 땐 가급적 다음 디자인 원칙을 지키며 작성해야합니다.
동일 리소스에 대한 API 요청은 모두 동일하게 보여져야합니다.
Stateless
는 무상태성을 의미합니다. 무상태성은 작업을 위한 상태정보를 따로 저장하거나 관리하지 않는다는 의미입니다. 그래서 REST API
는 들어오는 요청에 대해서만 처리를 하도록 만들어야합니다.(구현이 단순해지는 특성을 가짐)
클라이언트는 사용자에 대한 정보를 직접 관리, 서버는 API를 제공함으로써 독립적인 구조를 가져야합니다. 독립적 구조 덕에 분업 및 관리가 쉬워집니다.
리소스를 클라이언트 또는 서버측에서 캐싱 가능해야합니다. 이 덕에 서버는 확장성이 높아지고 클라이언트는 성능이 높아집니다.
REST API
는 여러 계층으로 설계될 수 있습니다. 이때 보안, 로드 밸런싱, 암호화 층 등으로 구조 유연성을 챙기거나 프록시, 게이트웨이 등으로 중간 매체를 활용할 수 있도록 만들어 줍니다.
일반적인 상황에서 REST API
는 정적 리소스를 전송하지만, 특수한 상황에서 실행 코드를 넣을 수 있는데, 이때 코드는 요청시에만 실행되도록 해야합니다.
이번엔 설계 규칙에 대해서 알아보겠습니다. 디자인 원칙은 설계 하기 전에 염두해야할 사항이라면 설계 규칙은 설계를 실제로 할 때 지켜야하는 사항들입니다.
/
, -
, _
의 사용/
는 기본적으로 계층 관계를 나타낸다.-
은 띄어 쓰기를 대체하여 가독성을 높이는데만 사용한다._
는 사용하지 않는다.그러면 REST API
를 어떻게 사용하는지 간단한 표를 통해 확인하고 마무리하겠습니다.
종류 | 기능 |
---|---|
POST /posts | 포스트 추가 |
GET /posts | 포스트 목록 가져오기 |
GET /posts/:id | 특정 id의 포스트 가져오기 |
DELETE /posts/:id | 특정 id의 포스트 삭제하기 |