Restful API

RESTful API란?

RESTful API는 두 컴퓨터 시스템이 인터넷을 통해 정보를 안전하게 교환하기 위해 사용하는 인터페이스다.

API란 애플리케이션 프로그래밍 인터페이스로, 다른 소프트웨어 시스템과 통신하기 위해 따라야 하는 규칙이다. 개발자는 다른 애플리케이션이 프로그래밍 방식으로 애플리케이션과 통신할 수 있도록 API를 표시하거나 생성한다. 웹 API는 클라이언트(웹에서 정보에 액세스하려는 사용자)와 웹 리소스(다양한 애플리케이션이 클라이언트에게 제공하는 정보) 사이의 게이트웨이라고 생각할 수 있다.

REST는 Representational State Transfer로, API 작동 방식에 대한 조건을 부과하는 소프트웨어 아키텍처다.

API 개발자는 여러 아키텍처를 사용하여 API를 설계할 수 있다. REST 아키텍처 스타일을 따르는 API를 REST API라고 한다. REST 아키텍처를 구현하는 웹 서비스를 RESTful 웹 서비스라고 한다. REST API와 RESTful API라는 용어는 같은 의미로 사용할 수 있다.

 

REST 아키텍처 스타일의 몇 가지 원칙

균일한 인터페이스

균일한 인터페이스는 모든 RESTful 웹 서비스 디자인의 기본이며, 서버가 표준 형식으로 정보를 전송함을 나타낸다. 형식이 지정된 리소스를 REST에서 표현이라고 부른다. 이 형식은 서버 애플리케이션에 있는 리소스의 내부 표현과 다를 수 있다.

• 균일한 인터페이스의 4가지 아키텍처 제약 조건
  1. 요청은 리소스를 식별해야 한다. 이를 위해 균일한 리소스 식별자를 사용한다.
  2. 클라이언트는 원하는 경우 리소스를 수정하거나 삭제하기에 충분한 정보를 리소스 표현에서 가지고 있다. 서버는 리소스를 자세히 설명하는 메타데이터를 전송하여 이 조건을 충족한다.
  3. 클라이언트는 표현을 추가로 처리하는 방법에 대한 정보를 수신한다. 이를 위해 서버는 클라이언트가 리소스를 적절하게 사용할 수 있는 방법에 대한 메타데이터가 포함된 명확한 메시지를 전송한다.
  4. 클라이언트는 작업을 완료하는 데 필요한 다른 모든 관련 리소스에 대한 정보를 수신한다. 이를 위해 서버는 클라이언트가 더 많은 리소스를 동적으로 검색할 수 있도록 표현에 하이퍼링크를 넣어 전송한다.

무상태

REST 아키텍처에서 무상태는 서버가 이전의 모든 요청과 독립적으로 모든 클라이언트 요청을 완료하는 통신 방법을 나타낸다. 클라이언트는 임의의 순서로 리소스를 요청할 수 있으며 모든 요청은 무상태이거나 다른 요청과 분리된다. 이 REST API 설계 제약 조건은 서버가 매번 요청을 완전히 이해해서 이행할 수 있음을 의미한다.

계층화 시스템

계층화된 시스템 아키텍처에서 클라이언트는 클라이언트와 서버 사이의 다른 승인된 중개자에게 연결할 수 있으며 여전히 서버로부터도 응답을 받는다. 서버는 요청을 다른 서버로 전달할 수도 있다. 클라이언트 요청을 이행하기 위해 함께 작동하는 보안, 애플리케이션 및 비즈니스 로직과 같은 여러 계층으로 여러 서버에서 실행되도록 RESTful 웹 서비스를 설계할 수 있다. 이러한 계층은 클라이언트에 보이지 않는 상태로 유지된다.

캐시 가능성

RESTful 웹 서비스는 서버 응답 시간을 개선하기 위해 클라이언트 또는 중개자에 일부 응답을 저장하는 프로세스인 캐싱을 지원한다. RESTful 웹 서비스는 캐시 가능 또는 캐시 불가능으로 정의되는 API 응답을 사용하여 캐싱을 제어한다.

온디맨드 코드

REST 아키텍처 스타일에서 서버는 소프트웨어 프로그래밍 코드를 클라이언트에 전송하여 클라이언트 기능을 일시적으로 확장하거나 사용자 지정할 수 있다.

 

RESTful API의 장점

확장성

REST API를 구현하는 시스템은 REST가 클라이언트-서버 상호 작용을 최적화하기 때문에 효율적으로 크기 조정할 수 있다. 무상태는 서버가 과거 클라이언트 요청 정보를 유지할 필요가 없기 때문에 서버 로드를 제거한다. 잘 관리된 캐싱은 일부 클라이언트-서버 상호 작용을 부분적으로 또는 완전히 제거한다. 이러한 모든 기능은 성능을 저하시키는 통신 병목 현상을 일으키지 않으면서 확장성을 지원한다.

유연성

RESTful 웹 서비스는 완전한 클라이언트-서버 분리를 지원한다. 각 부분이 독립적으로 발전할 수 있도록 다양한 서버 구성 요소를 단순화하고 분리한다. 서버 애플리케이션의 플랫폼 또는 기술 변경은 클라이언트 애플리케이션에 영향을 주지 않는다. 애플리케이션 함수를 계층화하는 기능은 유연성을 더욱 향상시킨다.

독립성

REST API는 사용되는 기술과 독립적이다. API 설계에 영향을 주지 않고 다양한 프로그래밍 언어로 클라이언트 및 서버 애플리케이션을 모두 작성할 수 있다. 또한 통신에 영향을 주지 않고 양쪽의 기본 기술을 변경할 수 있다.

 

RESTful API 클라이언트 요청의 구성요소

고유 리소스 식별자

서버는 고유한 리소스 식별자로 각 리소스를 식별한다. REST 서비스의 경우 서버는 일반적으로 URL(Uniform Resource Locator)을 사용하여 리소스 식별을 수행한다. URL은 리소스에 대한 경로를 지정한다. URL은 웹페이지를 방문하기 위해 브라우저에 입력하는 웹 사이트 주소와 유사하다. URL은 요청 엔드포인트라고도 하며 클라이언트가 요구하는 사항을 서버에 명확하게 지정한다.

메서드

개발자는 종종 Hypertext Transfer Protocol(HTTP)을 사용하여 RESTful API를 구현한다. HTTP 메서드는 리소스에 수행해야 하는 작업을 서버에 알려준다. 

• 4가지의 일반적인 HTTP 메서드
  • GET - 클라이언트는 GET을 사용하여 서버의 지정된 URL에 있는 리소스에 액세스한다. GET 요청을 캐싱하고 RESTful API 요청에 파라미터를 넣어 전송하여 전송 전에 데이터를 필터링하도록 서버에 지시할 수 있다.
  • POST - 클라이언트는 POST를 사용하여 서버에 데이터를 전송한다. 여기에는 요청과 함께 데이터 표현이 포함된다. 동일한 POST 요청을 여러 번 전송하면 동일한 리소스를 여러 번 생성하는 부작용이 있다.
  • PUT - 클라이언트는 PUT을 사용하여 서버의 기존 리소스를 업데이트한다. POST와 달리, RESTful 웹 서비스에서 동일한 PUT 요청을 여러 번 전송해도 결과는 동일하다.
  • DELETE - 클라이언트는 DELETE 요청을 사용하여 리소스를 제거한다. DELETE 요청은 서버 상태를 변경할 수 있다. 하지만 사용자에게 적절한 인증이 없으면 요청은 실패한다.

•  

HTTP 헤더

요청 헤더는 클라이언트와 서버 간에 교환되는 메타데이터다. 요청 헤더는 요청 및 응답의 형식을 나타내고 요청 상태 등에 대한 정보를 제공한다.

데이터

• REST API 요청에는 POST, PUT 및 기타 HTTP 메서드가 성공적으로 작동하기 위한 데이터가 포함될 수 있다.

파라미터

RESTful API 요청에는 수행해야 할 작업에 대한 자세한 정보를 서버에 제공하는 파라미터가 포함될 수 있다.

• 파라미터 유형
  • URL 세부정보를 지정하는 경로 파라미터
  • 리소스에 대한 추가 정보를 요청하는 쿼리 파라미터
  • 클라이언트를 빠르게 인증하는 쿠키 파라미터

 

RESTful API 서버 응답

상태 표시줄

상태 표시줄에는 요청 성공 또는 실패를 알리는 3자리 상태 코드가 있다.

2XX 코드는 성공을 나타내고 4XX 및 5XX 코드는 오류를 나타낸다. 3XX 코드는 URL 리디렉션을 나타낸다.

• 200: 일반 성공 응답
• 201: POST 메서드 성공 응답
• 400: 서버가 처리할 수 없는 잘못된 요청
• 404: 리소스를 찾을 수 없음

메시지 본문

응답 본문에는 리소스 표현이 포함된다. 서버는 요청 헤더에 포함된 내용을 기반으로 적절한 표현 형식을 선택한다.

클라이언트는 데이터 작성 방식을 일반 텍스트로 정의하는 XML 또는 JSON 형식으로 정보를 요청할 수 있다. 

ex) '{"name":"John", "age":30}'

헤더

응답에는 응답에 대한 헤더 또는 메타데이터도 포함된다. 이는 응답에 대한 추가 컨텍스트를 제공하고 서버, 인코딩, 날짜 및 콘텐츠 유형과 같은 정보를 포함한다.

 

REST API 가 아닌 것: SOAP API

SOAP API란?

SOAP(Simple Object Access Protocol)는 그 자체로 프로토콜이며, 보안이나 메시지 전송 등에 있어서 REST보다 더 많은 표준들이 정해져있기 때문에 조금 더 복잡하다. 이러한 표준들로 인해서 오버헤드가 많기는 하지만, 보안, 트랜잭션, ACID(원자성, 일관성, 고립성, 지속성)을 준수해야 하는 보다 종합적인 기능이 필요한 조직에게는 적합한 방식이 될 수 있다. SOAP는 웹 서비스 시나리오에 적용하기에는 그다지 좋지 않기 때문에, 기업용 애플리케이션 등을 작업하는데 더 이상적이라고 말할 수 있다.

‘SOAP vs REST 차이’ : 핵심적인 차이들

 

---

출처

https://aws.amazon.com/ko/what-is/restful-api/

https://blog.wishket.com/soap-api-vs-rest-api-%EB%91%90-%EB%B0%A9%EC%8B%9D%EC%9D%98-%EA%B0%80%EC%9E%A5-%ED%81%B0-%EC%B0%A8%EC%9D%B4%EC%A0%90%EC%9D%80/