API?

Application Programming Interface

API = 서로 다른 소프트웨어 시스템들이 상호 작용할 수 있게 하는 인터페이스.
즉, 다른 소프트웨어 시스템과 통신하기 위해 따라야 하는 규칙을 정의한다.

쉽게 생각하면 은행 창구라고 볼 수 있다.

1. 고객(클라이언트)이 은행(서버)에 은행 업무를 보러 들린다.
2. 은행 창구로 가서 고객은 원하는 업무를 말하고 필요한 서비스를 받는다.
3. 직원은 고객이 요청한 업무를 처리하고 결과를 알린다.
   (이 과정에서 고객은 직원이 어떤 시스템으로 일을 하는지 전혀 알 필요가 없다.)
4. 직원은 고객이 요청한 업무에 필요한 정보(개인정보)를 확인하고 요청을 처리한다.

REST?

Representational State Transfer

REST = API 작동 방식에 대한 조건을 부과하는 SW 아키텍처.
클라이언트-서버 구조에서 데이터를 전송하는 방식으로 특히 웹에서 리소스를 관리하고 조직하는데 많이 쓰임.

알아야 할 것

1. Resource : URI를 통해 식별되는 데이터, 객체
2. Representation : 자원의 상태를 클라이언트에게 전달하는 방식. JSON, XML...
3. HTTP Method : GET, POST, PUT, DELETE 등등..
4. URI : Uniform Resource Identifier의 약자로 자원을 식별하는 식별자

특징

1. Server-Client 구조
2. Stateless : 서버는 클라이언트의 상태를 저장하지 않음. 즉, 클라이언트는 요청에 모든 정보를 담아야함 (맥북 a1 2개를 카드로 결제할께요)
3. Cacheable : Http의 특징인 캐싱 기능을 사용할 수 있다.
4. Layered System : 서버가 계층화 되어있어서 클라이언트는 중간 서버를 통해서도 자원에 접근이 가능하다.
5. Uniform Interface : URI로 지정한 리소스에 대해 모든 조작을 통일하고, 한정적인 인터페이스로 수행함.
6. Self-descriptiveness : 요청과 응답이 자체적으로 충분한 정보를 포함해서 보자마자 이해가 가능함.

규칙

1. URI는 명사를 사용한다.
2. 행위는 HTTP 메소드로 표현한다.
3. /로 계층 관계를 표현한다. (마지막은 사용 x)
4. URI는 소문자로만 구성한다.
5. 가독성이 떨어진다면 -을 사용한다. _ 는 사용하지 않는다.
6. 파일 확장자는 URI에 포함하지 않는다.

REST API?

REST 아키텍처 스타일을 따르는 API

API가 다음 기준을 만족하면 REST API로 분류된다.
1. Client, Server, Resource로 구성되며 요청이 HTTP를 통해 관리된다.
2. Client - Server 커뮤니케이션이 Stateless 하다.
3. Cacheable : Client - Server 작용을 간소화하는 캐시 가능 데이터
4. 요청된 정보를 검색하는데 관련된 서버의 각 유형을 클라이언트가 볼 수 없는 계층 구조로 이뤄져 있다.

참고

AWS
nias0327