REST API에서 REST는 "Representational State Transfer"의 약자이다.
자원(resource)의 표현(representation)에 의한 상태(state) 전달(transfer)인 것이다. 여기서 '자원'은 문서든 이미지든 데이터 등 해당 소프트웨어가 관리하는 모든 것을 의미한다. 이러한 자원의 '표현'은 자원을 명시하는 것이라고 할 수 있다. '상태 전달'은 데이터가 요청되는 시점에서 자원의 상태(정보)를 전달하는 것을 말한다.

정리해보면, REST API는 웹에서 사용하는 데이터나 자원을 HTTP URI로 표현하고, HTTP 프로토콜을 통해 요청과 응답을 정의하는 방식이다.

REST API는 POST(Create), GET(Read), PUT(Update), DELETE(Delete)로 구성되어 있다. 이러한 메서드를 이용해 요청하면, JSON이라는 포맷을 통해 서버로부터 응답을 받아올 수 있다.

HTTP 프로토콜을 기반으로 요청과 응답에 따라 리소스(Resource)를 주고 받기 위해서 알아보기 쉽게 잘 작성된 기준이 필요하다. 이 역할을 API가 수행하게 되기 때문에 API는 모두가 잘 알아볼 수 있도록 작성하는 것이 중요하다.

REST 성숙도 모델

적절한 REST API를 잘 작성하기 위한 레오나르드 리차드슨의 4단계(0~3단계) REST 성숙도 모델이 있다. 로이 필딩은 이 모델의 모든 단계를 충족해야 REST API라고 부를 수 있다고 주장하지만, 실제로는 3단계까지 지키기 어렵기 때문에 2단계까지만 적용해도 HTTP API라고 볼 수 있다.

0단계

HTTP/1.1

0단계에서는 단순히 HTTP 프로토콜을 사용하기만 하면 된다.
0단계만 충족한 API는 REST API라고 할 수는 없고, REST API를 작성하기 위한 기본 단계로 보아야 한다.

1단계

// 요청하는 리소스에 따라 각기 다른 엔드포인트로 구분
POST /doctors/Kim HTTP/1.1
POST /slots/123 HTTP/1.1

// 두 번째 요청에 대한 응답
HTTP/1.1 409 Conflict
[헤더 생략]
{
	...
    "reason": "예약 불가"
    ...
}

1단계에서는 개별 리소스와의 통신을 준수해야 한다.

REST API는 웹에서 사용되는 모든 데이터나 리소스를 HTTP URI로 표현하기 때문에, 모든 리소스는 개별 리소스에 맞는 엔드포인트(Endpoint)를 사용해야 한다.

➡ 엔드포인트 작성 시 동사나 HTTP 메서드, 행위에 대한 단어 사용은 지양하고, 리소스에 집중해 명사 형태의 단어로 작성하는 것이 바람직하다.

또 요청에 따른 응답으로 리소스를 전달할 때, 리소스에 대한 정보와 함께 사용에 대한 성공/실패 여부를 응답으로 전달해야 한다.

2단계

// HTTP 메서드 사용하여 요청
GET /doctors/Kim/slots?date=2022-10-06 HTTP/1.1
POST /slots/123 HTTP/1.1

// POST에 대한 응답
HTTP/1.1 201 Created
Location: slots/123/appointment

2단계는 CRUD에 맞게 적절한 HTTP 메서드를 사용하는 것에 중점을 둔다.

위 예시는 조회(READ)를 하기 위해 GET 메서드로 요청을 보내고, 예약을 생성(CREATE)하기 위해 POST 요청을 보낸 것이다.

• GET 메서드는 body를 가지지 않기 때문에 query parameter를 사용하여 필요한 리소스를 전달한다.

• POST 요청은 응답이 어떻게 반환되는지가 중요하다. 응답은 새롭게 생성된 리소스를 보내주기 때문에, 위 예시에서 201 Create와 같은 응답 코드가 존재한다.
  관련 리소스를 클라이언트가 Location 헤더에 작성된 URI를 통해 확인할 수 있도록 하면 REST API 설숙도 모델의 2단계를 충족했다고 볼 수 있다.

HTTP 메서드 사용 규칙

• GET 메서드: 웹 페이지나 데이터를 요청하는 메서드이다. 서버의 데이터를 변화시키지 않는 요청에 사용한다.

• POST 메서드: 새로운 글이나 데이터를 전송하는 메서드이다. 요청마다 새로운 리소스를 생성한다.

• PUT 메서드: 요청마다 같은 리소스를 반환한다.

  • 매 요청마다 같은 리소스를 반환하는 특징을 "멱등idempotent"하다고 하는데, 멱등성을 가지는 PUT과 그렇지 않은 POST를 구분하여 사용해야 한다.
  • PUT 메서드는 PATCH 메서드와 다르게, 교체의 용도로 사용된다.

• PATCH 메서드: 수정의 용도로 사용된다.

3단계

// 헤더 아래의 응답 내용
{
	...
},
	// 예약을 다시 확인할 수 있도록 링크 작성
	"links" : {
    		"self" : {
            	"href" : "http://localhost:8080/slots/123"
                "method" : "GET"
            },
    		"cancel" : {
            	"href" : "http://localhost:8080/slots/123/cancel"
                "method" : "DELETE"
            }
    }

마지막 단계는 HATEOAS(Hypertext As The Engine Of Application State)
라는 약어로 표현되는 하이퍼미디어 컨트롤을 적용한다.

요청은 2단계와 동일하지만, 응답은 리소스의 URI를 포함한 링크 요소를 삽입하여 작성해야 한다. 이 링크 요소는 많은 하이퍼미디어 컨트롤을 포함하고 있어 응답을 받은 이후 다양한 액션들을 할 수 있다.

위 예시와 같이, 응답 내에서 새로운 링크를 넣어 새로운 기능에 접근할 수 있도록 하는 것이 3단계의 핵심이다.

Open API와 API Key

Open API (Public API)

말 그대로 누구에게나 열려 있는 API이다. 회사 내부에서 사용하는 Web API를 외부의 다른 개발자가 이용할 수 있도록 공개적으로 오픈한 것이라고 할 수 있다.

API마다 정해진 이용 수칙이 있고, 그에 따른 제한 사항이 있어 무제한으로 이용할 수 있다는 것은 아니다.

ex) Open Weather Map

API Key

서버 운용에 비용이 발생하고, 서버 입장에서 조건 없이 익명의 클라이언트에게 데이터를 제공해줄 의무는 없기 때문에 API를 이용하기 위해서는 API Key가 필요하다. (API Key가 필요하지 않은 경우도 존재한다.)

API Key가 필요한 경우, 데이터를 요청할 때 API Key를 같이 전달해야 원하는 응답을 받을 수 있다. 응답 측에서는 로그인한 이용자에게 자원에 접근할 수 있는 권한을 API Key 형태로 제공한다.

🔥 추가 학습 링크

• 구글 REST API 작성 가이드라인
• 마이크로소프트 REST API 작성 가이드라인