API (Application Programming Interface)
애플리케이션 간의 상호작용을 가능하게 해주는 인터페이스입니다. 즉, API는 서로 다른 소프트웨어들이 소통할 수 있도록 도와주는 중개인 역할을 합니다. 예를 들어, 우리가 스마트폰에서 날씨 애플리케이션을 사용할 때, 앱이 현재의 날씨 데이터를 보여주기 위해 날씨 서버에 요청을 보내고 응답을 받는 과정에서 API가 중요한 역할을 합니다.
API는 개발자의 삶을 크게 개선해줍니다. 기존에 구현된 서비스나 데이터를 다른 프로젝트에서 재사용하거나 타사의 기능을 가져와 빠르게 개발을 진행할 수 있기 때문입니다. 예를 들어, 결제 시스템을 구축할 때 자체적으로 모든 과정을 개발하는 대신, Stripe나 PayPal 같은 결제 서비스의 API를 사용해 간편하게 통합할 수 있습니다. 이를 통해 개발자들은 기본적인 기능 구현에 많은 시간을 절약하고 서비스의 핵심 기능에 집중할 수 있게 됩니다.
HTTP API?
HTTP를 사용하여 프로그램끼리 소통하는 방식으로 Web API라고도 부른다. HTTP를 사용해서 서로 정해둔 스펙으로 데이터를 주고 받는 API를 말한다.
통신 방법
- GET 방식
- 쿼리 파라미터를 이용하여 클라이언트와 통신하는 방법
- POST 방식
- Message Body에 쿼리 파라미터를 담아 클라이언트와 서버가 통신하는 방법
- Message Body
- HTTP API에서 주로 쓰이는 방식
- HTTP Message Body에 데이터를 직접 담아서 요청하는 방법
- 데이터 포맷 : XML, CSV, JSON(가장 많이 사용)
-> 데이터를 전달할 수 있도록 변환하게 만들어주는 확장자들
✏️ HTTP를 사용하지 않는 API가 있나?
- 저사양/저전력 환경에 적합한 MQTT, CoAp프로토콜을 사용하는 API가 존재한다.
- 예시 : IoT어플리케이션을 개발할 때 IoT 어플리케이션과 통신할 수 있는 API
REST API?
- REST (Representational State Transfer)
REST는 네트워크 아키텍처 스타일을 말한다. 아키텍처 스타일은 네트워크 자원을 정의하고 처리하는 방법. 즉, 제약 조건의 집합이다. REST API는 자원의 표현으로 상태를 전달하는 아키텍처로 만든 API이다. REST는 HTTP를 잘 활용하기 위한 원칙이 존재한다.
REST 구성요소
- 자원(Resource) : HTTP URI
- 자원에 대한 행위(Verb) : HTTP Method
- 자원에 대한 행위의 내용(Representations) : HTTP Message Pay Load
REST 특징
- Server-Client
- 서버-클라이언트는 각각의 역할이 있어 명확하고 서로간 의존성이 줄어듬. - Stateless
- 작업을 위한 상태 정보를 따로 저장하고 관리하지 않음.- 들어오는 요청만 단순 처리.
- 서비스의 자유도가 높아져 구현이 단순.
- Cacheable
- 웹표준을 그대로 사용하기 때문에 모든 서버 응답은 캐싱이 되는지 표현. - Layered System
- REST 서버는 다중 계층 가능.- 보안, 로드 밸런싱, 암호화 계층을 추가해 구조상의 유연성.
- Uniform Interface
- URI로 지정한 리소스 조작을 통일하고 한정적인 인터페이스로 수행하는 아키텍처- 전체 시스템 아키텍처가 단순
- 상호 작용의 가시성이 개선
REST API 제약 조건
HTTP API와 REST API는 사실 거의 비슷하고 같은 의미로 사용하고 있다. 차이점으로는 REST API는 HTTP 프로토콜을 따르면서 4가지 제약 조건을 지켜야한다.
1. 자원의 식별
2. 메세지를 통한 리소스 조작
3. 자기서술적 메세지
4. 애플리케이션의 상태에 대한 엔진으로서 하이퍼미디어(HATEOAS)
위 제약 조건을 지키며 개발하는 것을 RESTful API라고 한다.
실무에서는 이런 방법으로 개발하는 것이 어렵고 개발비용 대비 효과가 있지 않다고 한다. 이미 많은 사람들이 위 제약 조건들을 지키지 않아도 REST API라고 하기 때문에 HTTP API와 같은 의미로 사용하고 있다.
RESTful API?
REST 제약 조건을 따르는 시스템을 RESTful이라는 용어로 지칭한다.
RESTful Design Guide
- URI로 자원(리소스)를 표현해야 한다.
- 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE)로 표현된다.
1. 정보의 자원을 표현
document, collection, store, controller 4가지 방식으로 자원을 표현한다.
- document : 객체 인스턴스와 유사한 개념. REST에서는 리소스 집합(collection)중 하나로 표현되며 일반적으로 단수 명사로 collection의 뒤에 / (슬래시)를 통해 구분된다.
- collection : Resource(document)들의 집합. 서버에서 관리하는 directory라는 리소스
- store : 클라이언트에서 관리하는 리소스 저장소
http://restapi.example.com/sports/soccer/players/13위와 같은 방식의 URI를 보면 sports, players는 collection으로 나타나고, soccer, 13은 document로 URI를 구성하고 있다.
그 외 리소스 표현 방법
- 명사형을 사용
- 소문자 사용
- 밑줄( _ )은 사용 X
- 하이픈( - ) 사용
2. 자원에 대한 행위 표현
GET /members/delete/1 (x)
DELETE /members/1 (o)URI는 자원을 표현하는데 중점을 두어야 한다. URI에 HTTP Method가 들어가면 안되고 행위에 대한 표현도 들어가서는 안된다. 행위를 표현할 때는 HTTP Method로 표현한다.
GET /members/show/1 (x)
GET /members/1 (o)회원정보를 가져오는 행위는 GET 메소드를 사용하여 URI를 표현한다.
GET /members/insert/2 (x)
POST /members/2 (o)회원을 추가하는 행위는 POST 메소드를 사용하여 URI를 표현한다.
3. 경로에 대한 표현
/company/employee (o)
/company/employee/ (x)URL 마지막은 계층 관계가 아니기 때문에 슬래시로 구분하지 않습니다.
정리
REST가 필요한 이유
- 애플리케이션 분리 및 통합
- 다양한 클라이언트의 등장
- 서버는 다양한 모바일 디바이스에서 통신할 수 있어야 함
RESTful API를 구현하는 목적
- 이해하기 쉽고 호환성이 높은 REST API를 제공하기 위해
- 성능이 중요한 경우는 RESTful하게 할 필요는 없다.
RESTful 하지 못한 경우 example
- CRUD 기능을 모두 POST로만 처리하는 API
- route에 resource, id외 정보가 들어가는 경우
참고
https://bentist.tistory.com/37
https://coco16.tistory.com/10
https://velog.io/@beneficial/HTTP%EC%99%80-REST-API%EC%9D%B4%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80
