먼저 API에 대해서 먼저 알고가자.

API

• API는 응용프로그램이 어떤 프로그램을 제공하는 기능을 사용할 수 있게 만든 매개체. 컴퓨터와 소프트웨어를 연결한다.
• 클라이언트는 API를 사용하고 서버는 API를 통하여 클라이언트한테 리소스를 공유한다.

HTTP API

• HTTP API는 HTTP를 사용하여 프로그램끼리 소통하는 API를 말한다. 우리가 흔히 보는 Open API가 이에 속한다.

HTTP API 특징 (REST API도 적용)

• Client-Server
  • 데이터 저장에 대한 관심사와 사용자 인터페이스에 대한 관심사 분리하는 원칙이다.
  • 클라이언트 측면에서는 여러 플랫폼에 대한 사용자 인터페이스의 이식성(특정 환경에서 동작하는 SW를 다른 환경으로 변경해서도 동작할 수 있는 능력)을 개선한다.
  • 서버 측면에서는 서버측의 구성요소를 단순화 하여 확장성(성능요구에 맞게 시스템 확장)을 개선한다.
• Stateless(무상태)
  • 클라이언트가 서버로 요청을 보낼때 서버가 요청을 이해하기 위해 필요한 정보가 포함 되어있어야 한다는 원칙이다.(이때는 서버측에 저장된 정보는 이용못함)
  • 따라서 세션에 대한 정보는 전적으로 클라이언트에 보관한다..
  • 서버가 클라이언트 정보를 기억 하지 못한다.
  • 매번 요청할 때 부가정보를 보내야 해서 Stateful보다는 더 많은 데이터가 소모된다.
  • Stateful(상태유지)
    • 서버에서 클라이언트의 이전 단계 정보를 저장하고 있는 상태이다.
    • 서버가 터져가지고 다른 서버 사용해야 할 때 문제가 발생한다.
  • 보통 기본으로는 Stateless, 로그인은 로그인 상태를 유지해야 하기에 Stateful을 사용한다.
• Cache
  • 응답데이터가 cacheable한 지, non-cacheable한 지 암시적, 명시적으로 지정되어야 한다.
  • cacheable하면 클라이언트 캐시에 동일한 요청에 대해 응답 데이터를 재사용할 수 있는 권한을 부여한다.

REST API

• 웹상에서 사용하는 여러 리소스를 HTTP URL로 표현하고, 해당 리소스에 대한 행위를 HTTP Method로 정의하는 방식이다.
• REST는 네트워크 아키텍처 스타일로 HTTP를 잘 활용하기 위한 원칙이고 REST API는 이 원칙을 준수한 API이다.

REST API 특징

• Client-Server + Stateless + Cache

• Layered System(계층화)

  • Client는 REST API Server만 호출
  • REST Server는 다중 계층으로 구성한다.
    • API Server는 순수하게 비즈니스 로직만 수행한다.
    • 그 앞단에서 보안, 암호화, 사용자 인증등 등을 추가하여 구조상의 유연성 가능하다.
  • PROXY, 게이트웨이 같은 네트워크 기반의 중간매체 사용 가능한다.

• Uniform Interface(인터페이스 일관성)

  • 리소스가 URL로 식별되어야 한다. (자원의 식별)

  • 리소스를, 수정, 추가할때 HTTP메시지에 표현을 해서 전송한다. (메세지를 통한 리소스 조작)

    //올바른 REST
    
    예약 생성 : POST /reservation/2013012500001
    예약 수정 : PUT /reservation/2013012500001
    예약 조회 : GET /reservation/2013012500001
    예약 취소 : DELETE /reservation/2013012500001
    
    //잘못된 REST
    예약 생성 : POST /reservation/2013012500001?cmd=insert
    예약 수정 : POST /reservation/2013012500001?cmd=update
    예약 조회 : POST /reservation/2013012500001?cmd=select
    예약취소 : POST /reservation/2013012500001?cmd=delete

  • 메시지는 스스로 설명 가능해야 한다. (자기서술적 메시지)

    • 응답 결과에 보통 JSON 메시지를 사용하는데 이 JSON메세지가 어디에 전달되고 무엇으로 구성되어 있는지 표현해야 충족한다.
    • 쉽지 않다.....

  • 애플리케이션의 상태는 Hyperlink를 이용해 전이되야 한다. (HATEOAS 하이퍼미디어)

    • 서버가 요청을 할 때 요청에 필요한 URL를 응답에 포함시켜 반환한다.

    • 아래처럼 하면 client에서는 rel로 요청 URI를 사용하여서 client는 수정 안해도 된다.

      

      //Uniform Interface를 완벽하게 해주는 HAL JSON
      
      {
        "data": { // HAL JSON의 리소스 필드
          "id": 1000,
          "name": "게시글 1",
          "content": "HAL JSON을 이용한 예시 JSON"
        },
        "_links": { // HAL JSON의 링크 필드
          "self": {
            "href": "http://localhost:8080/api/article/1000" // 현재 api 주소
          },
          "profile": {
            "href": "http://localhost:8080/docs#query-article" // 해당 api의 문서 메세지 스스로 설명
          },
          "next": {
            "href": "http://localhost:8080/api/article/1001" // article 의 다음 api 주소 HATEOAS
          },
          "prev": {
            "href": "http://localhost:8080/api/article/999" // article의 이전 api 주소 HATEOAS
          }
        }
      }

RESTful API

• REST의 원리를 따르는 시스템이다.
• REST API 설계규칙 올바르게 지켜야 RESTful하다고 한다.
• 하지만 많은 사람들이 조건을 지키지 않아도 REST API라고 해서 HTTP API나 REST API를 같은 의미로 사용한다.
• 실무에서 RESTful API로 개발하는 것은 현실적으로 어렵고 추가 개발 비용대비 효과가 있는것도 아니여서 누군가 REST API라고 하면 그냥 아~ HTTP API를 이야기 하는구나 라고 생각하면 된다고 한다(엄격하게 보면 다름). - 킹영한님 말씀
• HATEOAS를 실제로 구현하기가 어렵다고 한다.

HTTP API vs REST API - 인프런

참고자료:

https://joomn11.tistory.com/26
https://coco16.tistory.com/10