REST API란?

들어가기에 앞서 API 가 뭔지부터 알아야겠다.

 

API(Application Programming Interface)

• 응용 프로그램에서 사용할 수 있도록, 운영 체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스
• 사용자 개입 없이 두 응용 프로그램이 서로 상호 작용할 수 있도록 하는 소프트웨어 인터페이스
• 서로 다른 소프트웨어가 서로 통신하고 데이터를 교환하도록 돕는 코드로 정의

 

이 정도로 정의할 수 있겠다. 많은 블로그들을 보면 API를 레스토랑을 예로 든다. 쪼끔 더.. 진짜 완전완전정말 쉬운 단 한 줄의 문장으로 표현하고 싶었는데 생각이 나질 않는다.. 

 

1. 손님은 직원을 불러 음식을 주문한다.

2. 직원은 셰프에게 음식을 요청한다.

3. 요리가 끝난 셰프가 직원에게 요리를 전달한다.

4. 직원은 손님이 주문한 음식을 제공한다.

 

여기서 손님은 요청을 하는(예시에서는 음식을 요청) 응용 프로그램이고 셰프는 전달하는 운영 체제(예시에서는 음식 전달)라고 할 수 있다. 이 둘 사이에서 연결을 하는 직원이 API이다! 메뉴는 API의 인터페이스라고 할 수도 있다.

 

API가 이러면 REST API는? REST한 방식으로 데이터를 상호교환 하도록 설계된 API겠지?

그리고 진정한 REST API는 REST의 제약조건을 모두 준수하는 것이라고 한다. (빨간색으로 표시한 것이 주로 안 지켜진다고 한다.)

 

그럼 이제 궁금해야 한다. REST가 무엇인지.....

 

 

REST(Representational State Transfer) 

• API 작동 방식에 대해 조건을 부과하는 소프트웨어 아키텍처
• HTTP를 잘 사용하기 위한 아키텍처 스타일
• URI와 HTTP 메서드를 사용해서 자원과 행위 표현

 

REST 제약조건

• Client-Server
  • Client와 Server를 분리해서, 서로 의존하지 않는 구조를 가져야 한다. 
  • 사용자 인터페이스에 대한 관심사 데이터 스토리지 문제에 대한 관심사를 분리한다.
  • 확장성을 개선하여 분산 시스템을 효율적으로 사용할 수 있다.
• Stateless
  • 무상태성 = 서로의 상태를 기억하지 않는다. 
  • 클라이언트에서 서버로의 요청에는 요청을 이해하는데 필요한 모든 정보가 포함되어야 한다.
  • 서버에 저장된 콘텍스트를 사용할 수 없다. 
  • 세션 상태는 전적으로 클라이언트에 유지되어야 한다.
  • 확장을 쉽게 할 수 있다.
• Cacheable
  
  • 요청애 대한 응답 내의 데이터에 캐시 가능여부가 명시되어 있어야 함을 의미한다.
  •  cacheable 하다고 응답되면 클라이언트는 동일한 요청에 응답 데이터를 재사용할 수 있다.
  • HTTP Header의 cache-control에 명시되어 있다.
• Uniform Interface 
  • API를 사용하는 클라이언트들에게 노출될 API 자원(Resource)에 대한 균일한 API 인터페이스를 결정해야 한다.
  • 균일한 인터페이스는 4가지 제약을 따른다.
    • 리소스 식별 (Indentification of Resources) 
      • 자원이 URI로 식별되면 된다.
      • ex) 회원 정보 조회 -> /mebers/{id} 
      • ex) 회원 등록 -> /mebers
    • 표현을 통한 자원 조작(Manipulation Of Resource through Representations)
      • 특정 리소스를 나타내는 URL을 바꾸지 않고도, 표현을 활용해서 자원을 조작할 수 있다.
      • HTTP 메서드인 GET, POST, PUT, DELETE 등을 활용해서 리소스를 조작할 수 있다.
      • 여러 클라이언트가 동일한 URL에서 새로운 리소스의 표현을 제공할 수 있다. 
      • 클라이언트와 서버가 유연하게 분리된다.
    • 자기 서술적인 메시지 (Self-descriptive messages)
      • Request와 Response와 같은 메시지는 그 자체로 무슨 의미인지 파악할 수 있을 정도의 정보가 담겨있어야 한다.

      •  HTTP/1.1 200 OK
          Content-Type: application/json
        
          [ { "op": "remove", "path": "/name" } ] // op나 path가 무얼 의미하는지 모른다.

      •   HTTP/1.1 200 OK
          Content-Type: application/json-patch+json
        
          [ { "op": "remove", "path": "/name" } ] // json-patch+json 명세에 들어가서 찾아보면 무엇을 의미하는지 알게된다.

      • * json-patch+json 이 뭐냐면 간단하게 JSON 문서의 특정 부분을 추가, 제거 또는 변경한다고 한다. 예를 들어 명세에 들어가 보면 아래와 같이 나와있어서 정확한 의미를 파악할 수 있게 된다.

      •  { "op": "replace", "path": "/name", "value": "abc" },

    • HATEOAS (hypermedia as the engine of application state)
      • 애플리케이션 상태가 Hyperlink를 이용해 전이되어야 한다.
      • 클라이언트와 서버 간의 직접 연결이 필요하지 않게 되어 최소한의 리소스로 다수의 클라이언트에 서비스를 제공할 수 있도록 서버를 확장할 수 있다.
  • Layered System
    • 아키텍처를 계층형으로 구성해야 한다.
  • Code on Demend(Optional)
    • 서버에서 코드를 클라이언트로 보내서 실행할 수 있어야 한다. 
    • ex) 서버로 받은 JavaScript 파일을 브라우저에서 실행할 수 있어야 한다.

 

 

 

 

 

참고 출처
https://velog.io/@gimminjae/REST-API%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80-%EC%99%9C-%EC%82%AC%EC%9A%A9%ED%95%98%EB%8A%94%EA%B0%80

REST API란 무엇인가? 왜 사용하는가?

개발 초보를 위한 RESTful API 설계 가이드 (velog.io)

개발 초보를 위한 RESTful API 설계 가이드

REST의 기본 원칙 6가지 · Just Do It! And Then Some! (jaeseongdev.github.io)

REST의 기본 원칙 6가지