(항상 잘못된 정보가 포함되어 있을수 있습니다)
(잘못된 정보가 있다면 댓글로 피드백 부탁드리겠습니다)

API 란?

API는 Application Programming Interface의 약자이다.

인터페이스는 장치나, 시스템이랑 소통하거나 상호작용할수 있게 해주는 방법이라고 생각하면 된다.
User Interface UI 우리가 흔히 들어본 이말
유저와 시스템이 상호작용 할수 있게 해주는 방법 이라고 생각하면 된다.

그럼 User Interface가 아니라 Application Programming Interface는 뭘까

어플리케이션을 프로그래밍하는데 시스템과 상호작용할수 있게 해주는 방법
이라고 두리뭉실 얘기할수 있을것 같다.

User Interface는 유저와 상호작용하기위해 유저의 눈에 보일것이다. (버튼)

하지만 어플리케이션을 프로그래밍하는데 쓰이는 인터페이스 라는건 시스템과 시스템이 서로 상호작용 하는 방법이기때문에 굳이 우리눈에 보일 필요가 없다.

그래서 결국 어플리케이션을 프로그래밍할때 시스템과 상호작용하게 해주는 모든것을 말한다.

웹개발을 할때 서버에 있는 데이터베이스와 상호작용 할 수 있게 해주는것
앱개발을 할때 스마트폰의 블루투스 관련한 부분과 상호작용 할 수 있게해주는것
앱개발 및 웹개발을 할때 네이버가만든 시스템인 네이버지도와 상호작용 할 수 있게 해주는것

같은 예시가 있을것이다.

REST

그렇다면 RESTful API는 뭘까
RESTful이라는건 REST 아키텍쳐를 따른다는 뜻이다.
RESTful API라는건 REST 아키텍쳐를 잘 지켜서 설계된 API를 말한다.

아키텍쳐
소프트웨어의 구성요소를 연결하는 방법이나, 구성요소들의 관계 등을 어느 특정한 형태로 구조화함 으로써 소프트웨어 설계에 구조를 제공한다.

REST
Representational State Transfer의 약자로
어떤 리소스(Resource)를 표현(Representation)하여 구분짓고 해당 리소스의 상태(State)를 넘겨준다(Transfer) 라는 뜻이다.

여기서 리소스를 가지고 제공해주는 어플리케이션을 서버
리소스를 받는 어플리케이션을 클라이언트라고 한다.

이러한 REST 아키텍처를 따르는 API들을 RESTful API라고 부르는 것이다.

REST 디자인 원칙

https://restfulapi.net/

1. Uniform Interface

간단히 말해서 REST는 클라이언트와 서버 간의 상호 작용을 위한 일관되고 통일된 인터페이스를 정의합니다. 예를 들어, HTTP 기반 REST API는 표준 HTTP 메서드(GET, POST, PUT, DELETE 등)와 URI(Uniform Resource Identifiers)를 사용하여 리소스를 식별한다.
그렇기 때문에 HTTP 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하게 할수 있다.

2. Client - Server

관심사의 분리를 강제하여 클라이언트와 서버가 독립적이어야 한다.

사용자 인터페이스 관련 부분(클라이언트)과 데이터 저장 관련 부분(서버)을 분리함으로써 각 부분을 독립적으로 발전시킬수 있다.

클라이언트와 서버가 독립적으로 발전하는 동안에도, 우리는 반드시 클라이언트와 서버 간의 인터페이스 또는 계약이 깨지지 않도록 해야 한다.

3. Stateless

이는 각 요청에서 처리에 필요한 모든 정보를 포함해야 함을 의미한다.
또한 서버는 이전에 발생한 요청의 상태나 컨텍스트를 저장하거나 활용할 수 없다.
각 요청은 독립적으로 처리되어야 하며, 이전 상태에 의존하지 않아야 한다.

4. Cachable

서버 응답 시간을 개선하기 위해 그리고 량의 요청을 효율적으로 처리하기 위해 캐시가 요구된다.
캐시 사용을 통해 응답시간, 성능, 서버의 리소스 이용률을 향상시킬 수 있다

5. Layered System

서버는 다중 계층으로 구성 될 수 있다.
순수 비즈니스 로직을 수행하고 그 앞단에 보안, 로드밸런싱, 암호화, 사용자 인증 등을 추가하여 구조상의 유연성을 줄 수 있다.
하지만 클라이언트는 REST API 서버만을 호출해야 한다.

6. Code-On-Demand(optional)

서버로부터 코드를 받아 실행할수 있어야 한다.
반드시 충족할 필요는 없다.

API를 설계할때 RESTful하게 만드는 이유

일관성 있는 컨벤션을 통한 API의 이해하기 쉽고 사용하기 쉽게 만들기 위해서, 또한 호환성을 높이기 위해서 사용한다.

또한 RESTful API는 URI를 통해 리소스를 표현하고, HTTP 메서드를 통해 리소스에 대한 행위를 표현하여 명시적으로 API의 목적을 이해하기 쉽게 한다.

HTTP 패킷을 한번 예시로 들어보자

GET /user/userinfo/get_userData.htm?=signup_year=2023 HTTP/1.1

GET이라는 HTTP 메서드는 리소스에 대한 행위를 표현하고
/user/userinfo/get_userData.htm?=signup_year=2023 라는 URL는 리소스가
무엇인지를 표현한다.

그래서 이것만을 보고도 해당 API가 2023년에 회원가입 유저정보를 가져오는 목적을 가졌구나라고 이해할 수 있는것이다.

GraphQL과의 비교

GraphQL이란 RESTful API와 마찬가지로 API를 설계하는 접근 방식인데.

RESTfUL API가 아키텍쳐라면 GraphQL은 API 쿼리 언어이다.

요청을 정의하는 데 서버 측 애플리케이션에 의존하지 않고도 GraphQL을 API 호출에 사용할 수 있다.

서버측 애플리케이션에 의존한다는건
기존 RESTful API는 클라이언트가 서버가 정해둔 고정된 구조를 따라야 정해둔 리소스를 가져올수 있다것이다.

이런 고정된 구조는 사용하기 쉽지만 가장 효율적인 수단은 아니다.

또한 기존 RESTful API 항상 전체 데이터 세트를 반환 한다.
User정보를 받는다고 하면 User의 고유키, 닉네임, 프로필사진, 프로필사진 썸네일, 등등 유저랑 관련된 정보를 모두 받아야한다.

만약 User정보 도 받고싶고, User구매내역도 알고 싶다면
두번의 API를 호출해야 될 것이다.
이러한 처리를 하기위해 서버던 클라이언트던 많은 코드를 작성해야 했고 이는 불편함을 만들었다.

예시 일뿐 정확하지 않음 

요청
example.com/userinfo
example.com/userpurchasehistory

응답
{
    "name": "",
    "id": "",
    "rank": "",
    "profileImage": "",
    "profileThumb": ""
}

{
    "date": "",
    "price": "",
}

GraphQL은 쿼리 기반 솔루션이다.

쿼리
데이터베이스에 특정한 데이터를 보여달라는 요청

쿼리는 한 번의 API 요청 및 응답 교환에서만 정확한 데이터를 반환할 수 있다.
만약 User정보의 이름과 구매내역을 받고 싶다면?

예시 일뿐 정확하지 않음 

요청
query {
    user(userKey: "") {
        id
        purchasehistory
    }
}

응답
{
    "data": {
        "user": {
            "id": "",
            "purchasehistory": []
        }
    }
}

이처럼 GraphQL은

• 요청횟수도 줄이고
• 응답 사이즈도 줄이고
• 서버와 클라이언트 개발자 모두에게 부담을 덜어줄수 있다.

하지만 장점만 있는것은 아니다.

단점으로는

• 고정된 요청과 응답만 필요할 때에는 query로 인해 요청의 크기가 Restful보다 커질 수 있다.
• 캐싱이 REST보다 복잡하다.

가 있다.
그렇기 때문에 장단점을 생각해서 서비스에 맞는 방식을 고르면 될것 같다.