REST API

 

면접관 : REST api 개발 경험이 있다고 하셨는데 REST api의 동작 원리에 대해 설명해주세요.

면접관 :  MSA를 사용해서 구현한건 아니라는 말씀이시죠?

 

얼마전 면접에서 REST API에 대한 질문을 받았고 잘 대답하지 못했다.

그래서 API, REST API에 대해 내가 알고있던내용, 잘못알고있던 내용이 있는것 같아서 정리를 하려고한다.

API란?

API는 "Application Programming Interface"의 약어로, 응용 프로그램 간에 상호 작용할 수 있도록 설계된 인터페이스를 나타냅니다. 간단히 말해, 소프트웨어 애플리케이션들이 서로 통신하고 상호 작용할 수 있도록 하는 규칙 세트를 제공하는 도구나 메커니즘입니다.

 

클라이언트와 서버 사이의 데이터 전송 통신을 위한 규칙이나 룰, 방법

 

 

손님이 점원에게 음식을 시키면 점원이 주문을 받아서 요리사에게 요청한다

요리사는 음식을 만들어서 점원에게 주고 점원은 다시 해당 요리를 손님에게 전달해준다.

 

점원의 역할

점원은 손님에게 메뉴를 알려주고 주문을 받아 받은 주문을  요리사에게 요청한다.

완성된 요리를 받아서 손님에게 다시 전달해준다.

 

API의 역할

API(점원)는 프로그램(손님)에게 명령목록(메뉴)을 바탕으로 요청(주문)을 받아 응용프로그램(요리사)과 상호 작용하여 요청된 명령의 결과값(요리)을 전달한다.

 

1. API는 서버와 데이터베이스에 대한 출입구 역할을 한다.

2. API는 애플리케이션과 기기가 원활하게 통신할 수 있도록 한다.

3. API는 모든 접속을 표준화한다.

 

 

REST API란?

REST API는 REST 아키텍처 스타일의 디자인 원칙을 준수하는 API이다.

• REST는 Representational State Transfer 의 약자로 소프트웨어 프로그램 아키텍처의 한 형식 이다.
  • 즉, 자원을 이름 (자원의 표현) 으로 구분하여 해당 자원의 상태 (정보)를 주고 받는 모든 것을 의미한다.
• REST는 기본적으로 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에 웹의 장점을 최대한 활용할 수 있는 아키텍처 스타일이다.

 

REST API 구성

• Resource (자원) - URI
  • 모든 자원에 고유한 ID가 존재하고, 이 자원은 Server에 존재한다.
  • 자원을 구별하는 ID는 /orders/order-id/1 와 같은 HTTP URI 이다.
• Verb (행위) - HTTP method
  • HTTP 프로토콜의 Method를 사용한다.
  • HTTP 프로토콜은 GET, POST, PUT, PATCH, DELETE와 같은 메서드를 제공한다.
• Representation (표현)
  • REST에서 하나의 자원은 JSON, XML, TEXT, RSS 등 여러 형태의 Representation으로 나타낼 수 있다

 

REST API의 특징

• 클라이언트 / 서버 구조
  • 클라이언트는 유저와 관련된 처리를, 서버는 REST API를 제공함으로써 각각의 역활이 확실하게 구분되고 일괄적인 인터페이스로 분리되어 작동할 수 있게 한다
  • REST Server: API를 제공하고 비지니스 로직 처리 및 저장을 책임진다.
  • Client: 사용자 인증이나 context (세션, 로그인 정보) 등을 직접 관리하고 책임진다.
  • 서로 간 의존성이 줄어든다.
• 무상태성 (Stateless)
  • REST는 HTTP의 특성을 이용하기 떄문에 무상태성을 갖는다.
  • 상태 정보를 따로 저장하고 관리하지 않는다. 세션 정보나 쿠키 정보를 별도로 저장하고 관리하지 않기 때문에 API서버는 들어오는 요청만을 단순히 처리하면 된다.
  • 즉 서버에서 어떤 작업을 하기 위해 상태정보를 기억할 필요가 없고 들어온 요청에 대해 처리만 해주면 되기 때문에 구현이 쉽고 단순해진다.

• 캐시 처리 가능 (Cacheable)
  • HTTP라는 기존 웹표준을 사용하는 REST의 특징 덕분에 기본 웹에서 사용하는 인프라를 그대로 사용 가능하다.
    대량의 요청을 효율적으로 처리하기 위해 캐시가 요구된다.
  • 캐시 사용을 통해 응답시간이 빨라지고 REST Server 트랜잭션이 발생하지 않기 때문에 전체 응답시간, 성능, 서버의 자원 이용률을 향상 시킬 수 있다.
• 자체 표현 구조 (Self - descriptiveness)
  • JSON을 이용한 메시지 포멧을 이용하여 직관적으로 이해할 수 있고 REST API 메시지만으로 그 요청이 어떤 행위를 하는지 알 수 있다.
• 계층화 (Layered System)
  • 클라이언트와 서버가 분리되어 있기 때문에 중간에 프록시 서버, 암호화 계층 등 중간매체를 사용할 수 있어 자유도가 높다
• 유니폼 인터페이스 (Uniform)
  • Uniform Interface는 Http 표준에만 따른다면 모든 플랫폼에서 사용이 가능하며, URI로 지정한 리소스에 대한 조작을 가능하게 하는 아키텍쳐 스타일을 말한다
  • URI로 지정한 Resource에 대한 조작을 통일되고 한정적인 인터페이스로 수행한다.
  • 즉, 특정 언어나 기술에 종속되지 않는다.

 

 

REST API 중심 규칙

1. URI는 정보의 자원을 표현해야 한다.
   • GET /members/delete/1
   • 위 URI에는 delete와 같은 행위에 대한 표현이 있으면 안된다.
2. 자원에 대한 행위는 HTTP Method (GET, POST, PUT, DELETE 등)으로 표현한다.
   • DELETE /members/1
   • 위 URI 처럼 행위는 HTTP Method로 표현한다.

 

REST API 세부 규칙

1. 슬래시 구분자(/)는 계층 관계를 나타내는 데 사용한다
2. URI 마지막 문자로 슬래시(/)를 포함하지 않는다.
   • URI에 포함되는 모든 글자는 리소스의 유일한 식별자로 사용되어야 하며 URI가 다르다는 것은 리소스가 다르다는 것이다.
   • 역으로 리소스가 다르면 URI도 달라져야 합니다.
3. 하이픈(-)은 URI 가독성을 높이는데 사용한다
4. 밑줄(_)은 URI에 사용하지 않는다.
5. URI 경로에는 소문자가 적합하다.
6. 파일 확장자는 URI에 포함시키지 않는다.
   • REST API에서는 메시지 바디 내용의 포맷을 나타내기 위한 파일 확장자를 URI 안에 포함시키지 않는다.
     Accept header를 사용하자

 

URI와 URL

• URI - Uniform Resource Identifier
  • 통합 자원 식별자
  • 인터넷상의 리소스 자원자체를 식별하는 고유한 문자열 시퀀스
• URL - Uniform Resource Locator
  • 네트워크상에서 통합 자원(리소스)의 “위치”를 나타내기 위한 규약

 

 URI= 식별자, URL=식별자+위치

• elancer.co.kr은 URI입니다. 리소스의 이름만 나타내기 때문이다.
• 반면, https://elancer.co.kr은 URL입니다. 이름과 더불어, 어떻게 도달할 수 있는지 위치까지 함께 나타내기 때문이다. (프로토콜 ‘https’ 포함)

1. URL은 일종의 URI이다.
   • 즉, URI가 더 포괄적인 개념이며 URL은 이 안에 포함된다
2. URL은 프로토콜과 결합한 형태이다.
   • ex) https://www.elancer.co.kr > URL
   • https (프로토콜) + www.elancer.co.kr (URI)
3. URI는 그 자체로 이름이 될 수 있다.

 

 

 

 

 

RESR API 장단점

장점

• 확장성 : 서버와 클라이언트 사이의 인터페이스가 명확하여 서로간의 의존성이 낮음
• 재사용성 : HTTP 프로토콜을 사용하기 때문에 기존 웹 인프라 그대로 이용
• 유지보수 용이성 : 각각의 자원에 대한 명확한 URI 사용으로 쉽게 이해 가능
• 캐시 기능 : 서버 측의 부하 분산 가능
• 보안성 :플랫폼에 독립적

단점

• HTTP 프로토콜에 의존
• URI 설계가 복잡할 수 있음
• 상태 정보가 클라이언트와 서버 간에 전송될 수 있음
• 필요한 문서화와 테스트 등의 추가 작업 필요

 

API, REST API 비교

 

• 아키텍처의 제약 조건을 따르느냐의 여부
  • API : 제약 조건이 없거나 제한적
  • RESTful API : 아키텍처의 제약 조건을 모두 따르도록 설계
• 호환성 및 이식성
  • API : 일관성 있는 인터페이스를 제공하지 않을 수 있음
    • 다양한 프로그래밍 언어나 플랫폼에서 호환성이 있도록 개발
  • RESTful API : 시스템의 확장성과 이식성이 뛰어남
    • 표준 HTTP 메소드를 사용하여 인터페이스를 일관성 있게 디자인
    • 때문에 다양한 클라이언트에서 쉽게 이해하고 사용 가능
• 보안성과 안정성
  • API : 제한적인 보안성과 안정성
    • 제약 조건을 따르지 않거나 없음
  • RESTful API : 보안성 높음
    • 클라이언트-서버 구조, 무상태성, 캐시, 계층화, 유니폼 인터페이스 등의 제약 조건을 모두 따름

 

요약

API란

클라이언트와 서버 사이의 데이터 전송 통신을 위한 규칙이나 룰, 방법

 

REST API란?

REST한 API, HTTP 메서드와 URI만으로 자원을 표현하는 API

 

 

reference

• https://yozm.wishket.com/magazine/detail/53/
• https://velog.io/@somday/RESTful-API-%EC%9D%B4%EB%9E%80
• https://www.elancer.co.kr/blog/view?seq=74
• https://luvris2.tistory.com/530