1. API
소프트웨어 응용 프로그램에서 다른 소프트웨어의 구성요소 또는 서비스와 상호작용을 하기 위한 방식
쉽게 설명하면,
가게에서 고객은 음식을 주문하고, 점원은 주문내역을 주방장에게 전달하고, 음식을 다시 고객에게 전달
점원은 고객과 주방장 사이에서 상호작용을 도와주는 역할을 하는데 이를 api라고 부름
즉, 클라이언트(고객)와 서버(주방장) 사이에서 상호작용( 요청,응답)을 도와주는 중간자 역할을 api라고 함
+ openAPI란?
api: 자신의 서버에서 조회가 가능한 api
openAPI: 구글지도api, 카카오톡 로그인 api 등 모든 사람이 사용할 수 있는 api
2. REST
2.1. REST란?
1. 자원을 이름으로 구분하여, 2. 자원의 상태를 주고받는 설계 규칙
1) 자원을 이름으로 구분
- HTTP URI로 자원 명시
- HTTP Method로 해당 자원에 대한 CRUD Operation을 적용
HTTP Method : post, get, put, patch, delete
CRUD Operation : Create 데이터 생성 (post), Update 데이터 수정 (put, patch),
Read 데이터 읽기 (get), Delete 데이터 삭제 (delete)
예시
Get /movies/1
- 영화 정보가 자원일 경우, http URI로 자원 명시 -> /movies/1
- 해당 자원에 대한 CRUD Operation 적용 -> get
2) 자원의 상태를 주고받는 것
- 클라이언트는 데이터가 요청될때 자원의 상태(정보)를 전달
- 서버는 이에 대한 응답으로 자원의 상태(정보)를 제공
2.2. REST 6가지 제약조건
1) 인터페이스 일관성
- 명사,소문자 사용/ 동사는 사용 (x)
2) 무상태
- 서버는 이전 요청에 대한 정보는 저장하지 않고, 각 요청을 독립적으로 처리
3) 캐시 처리 가능
- 모든 api 응답에 대해 클라이언트가 캐싱 가능하게 만들어야 함
- 클라이언트는 모든 응답 데이터를 저장하고 재사용할 수 있도록 만듦
4) 계층화
- 클라이언트는 여러 중간 계층(프록시)을 거쳐 서버와 상호작용한다.
5) 요청에 의한 코드 실행
- 서버와 클라이언트 모드 필요한 코드만 보낼 것
6) 클라이언트/서버 구조
- 클라이언트와 서버의 역할을 분명히 나눌 것
3. REST API vs RESTful API
3.1. REST API
- REST의 설계 규칙을 기반으로 API를 구현한 것
- REST 규칙을 완벽히 준수하지 않아도 동작하는 api
3.2. RESTful API
- REST의 기본 원칙을 완벽하게 구현한 API
- 성능 향상보단 이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것이 목적
| 제약조건 | REST API | RESTful API |
| 인터페이스 일관성 | 지킬 수도, 그렇지 않을 수도 있음 | 일관성있는 URI와 HTTP 메소드를 사용하여 설계 |
| 무상태 | 독립적이어야 하지만 모든 api에서 엄격히 지킬 필요는 없음 | 모든 요청은 독립적이어야 함 |
| 캐시 처리 | 캐시 가능여부를 명시적으로 정의하지 않을 수 있음 | 모든 응답이 캐시 가능해야 함 |
| 계층화 | 계층화된 시스템을 사용하지 않아도 되며, 직접 서버와 연결할 수도 있음 | 계층화된 시스템 사용 |
| 요청에 의한 코드 실행 | 필요한 코드만 전송할 수도 있고 그렇지 않은 경우도 있음 | 필요한 코드만 전송 |
| 클라이언트/서버 구조 | 반드시 철저히 구분되지 않을 수 있음 | 클라이언트와 서버의 역할을 철저히 분리 |