API란?
API의 시초
API는하드웨어 독립성을 보장하기 위해서 생겨난 개념인데,
서로 다른 하드웨어 부품에 맞는 프로그래밍을 각각 하기보다는,
추상화 계층을 통해 한번만 작성한 코드를
여러 곳에서 공통적으로 사용할 수 있도록 하기 위해서 생겨났다.
Web API?
API는 개인 컴퓨터가 나오기 이전부터 존재한 개념으로 대체로 운영 체제의 라이브러리 개념으로 사용되어서 시스템에서 로컬로 작동했다.
그러나 시간이 지나며 API는 로컬에서 분리되어서 원격 API가 나타나게 되었다.
원격이란 API에 의해 조작되는 리소스가 요청을 보내는 컴퓨터의 외부에 있는 것을 의미하는데, 대부분 커뮤니케이션을 할 때 인터넷을 사용하기 때문에 대부분의 원격 API는 웹 API라고 할 수 있다.
Web API는 HTTP 요청 메세지 - XML/JSON 형식의 응답 메세지 형식을 가진다.
XML/JSON 형식은 쉽게 조작할 수 있는 데이터 표현 방식으로
서버에서 제공하는 Web API를 통해 각기 다른 기기(iOS, Android)에서 동일한 서버의 데이터를 읽어오거나 업데이트할 수 있다.
API의 정의와 기능
API는 Application Programing Interface의 약자로,
다른 소프트웨어 시스템과 통신하기 위해 따라야하는 규칙을 정의한다.
이렇게 통신의 규칙을 정하므로써 좋은 점은 뭘까?
-> 세세한 구현 방식을 알지 못하는 제품이나 서비스와 통신이 가능해지기 때문에 개발 시간과 비용을 간소화할 수 있다.
API는 또한 특정한 요청과 응답의 형식을 갖춘 "상호간 계약"으로 비유되기도 하는데
한쪽에서 특정한 방식으로 요청을 보내면, 다른 쪽에서 이에 응답을 다시 보내준다.
이러한 계약의 여러 형식들중 가장 보편적으로 쓰이는 방식이 REST인 것이다. (REST 이전에는 SOAP라는 프로토콜을 통해 XML을 주고 받았었다.)
API의 종류
- 프라이빗
기업 내부에서만 사용 가능함 - 파트너
특정 비즈니스 파트너와만 공유 가능함 - 퍼블릭
모두에게 제공되며, 제3자가 해당 API를 활용하여 새로운 기술을 만들어낼 수 있음
-> 일반 사용자에게 API를 공개하면 브랜드 인지도를 높이고 새로운 수익 채널을 확보할 수 있다는 장점이 있다.
REST란?
Representational State Transfer의 약자로, API 작동 방식에 대한 조건을 부과하는 소프트웨어 아키텍처이다. 여러 아키텍처로 API를 설계할 수 있는데, REST는 그 방식들중 한가지이다.
REST 아키텍처 스타일
균일한 인터페이스
- 요청은 리소스를 식별할 수 있어야 해서 각각의 요청마다 고유한 리소스 식별자(URL)를 사용한다.
- 클라이언트는 리소스를 수정하거나 삭제하기에 충분한 정보를 리소스 표현에서 가지고 있는다.
- 클라이언트는 표현을 추가적으로 처리하는 방법에 대한 정보를 수신한다.
- 클라이언트는 작업을 완료하는데 필요한 다른 모든 리소스에 대한 정보를 수신한다.
무상태(Stateless)
모든 요청은 다른 요청들과 분리되어 서버는 이전의 모든 요청과 독립적으로 모든 클라이언트 요청을 완료한다.
이렇게 하면 과거의 클라이언트 요청 정보를 유지할 필요가 없기 때문에 성능을 향상시킬 수 있다.
계층화 시스템
클라이언트와 서버 사이의 다른 중개자에게 연결될 수 있고, 서버는 요청을 다른 서버로 전달할 수 있다. 이러한 계층은 클라이언트에겐 보이지 않는 상태로 유지된다.
캐시 가능성
서버 응답 시간을 개선하기 위해 첫번째 응답 이후에 해당 이미지를 캐싱하여 다음 응답시 사용한다.
최근 Open API는 REST API를 정의하는 공통 표준으로 부상하여서 사용자는 별다른 추측 없이도 이를 이해할 수 있다.
장점
확장성, 유연성
완전한 클라이언트 - 서버 분리를 통해 각 부분이 독립적으로 발전할 수 있다. 예를 들어 서버의 기술 변경은 클라이언트에 영향을 주지 않는다.
독립성
REST API는 사용되는 기술과 독립적이므로 API 설계에 영향을 주지 않고 다양한 프로그래밍 언어로 클라이언트 및 서버 애플리케이션을 작성 가능하다.
REST API
1. 클라이언트가 서버에 지정된 형식으로 요청 전송
- 고유 리소스 식별자(=URL)
- 메서드(GET, POST, PUT, PATCH)
- HTTP Header(데이터, 파라미터)
2. 서버가 클라이언트를 인증하고 클라이언트의 요청 권한확인
3. 서버가 요청을 수신하고 처리
4. 서버가 클라이언트에게 응답 반환
- 상태 코드(200, 201, 400, 404)
200 일반적인 성공 응답
201 POST 성공 응답
400 서버가 처리하지 못하는 잘못된 요청
404 리소스 찾을 수 없음 - 메세지 본문
- Header
Reference
https://www.redhat.com/ko/topics/api/what-are-application-programming-interfaces
