코드스테이츠 블로깅 여덟번째 REST API

REST API 에 대해서 알아보자!

REST API ( RESTful API )란?

두 컴퓨터 시스템이 정보를 안전하게 교환하기위해 사용하는 인터페이스입니다.

대부분의 비지니스 애플리케이션은 다양한 데스크를 수행하기 위해 다른 내부 애플리케이션 및 서드 파티 애플리케이션과 통신해야합니다.

RESTful API는 안전하고 신뢰할 수 있으며 효율적인 소프트웨어 통신 표준을 따르므로 이러한 정보 교환을 지원합니다

 

참고 :

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

RESTful API란 무엇인가? - RESTful API 초보자 가이드 - AWS

REST  란?

Representational State Transfer ( REST )는 API 작동 방식에 대한 조건을 부과하는 소프트웨어 아키텍쳐입니다.

REST는 처음에 인터넷과 같은 복잡한 네트워크에서 통신을 관리하기 위한 지침으로 만들어ㅕㅆ습니다.

REST 기반 아키텍쳐를 사용하여 대규모의 고성능 통신은 안정적으로 지원할 수 있습니다. 

쉽게 구현하고 수정할수 있어 모든 API 시스템을 파악하고 여러 플랫폼에서 사용할 수 있습니다.

 

API 개발자는 여러 아키텍처를 사용하여 API를 설계할수 있습니다

REST아키텍쳐 스타일을 따르는 API를 REST API 라고 합니다 .

REST아키텍처를 구현하는 웹서비스를 RESTful 웹 서비스 라고 합니다

 

RESTful 웹 API라는 용어는 일반적으로 RESTful 웹 API를 나타냅니다,하하지만 REST API 와 RESTful API라는 용어는 같은 의미로 사용할수있습니다 

API 란?

애플리케이션 프로그래밍 인터페이스 ( API )는 다른 소프트웨어 시스템과 통신하기 위해 따라야 하는 규칙을 정의합니다

개발자는 다른 애플리케이션이 프로그래밍 방식으로 애플리케이션과 통신할 수 있도록 API를 표시하거나 생성합니다

웹 API는 클라이언트와 웹 리소스 사이의 게이트웨이라고 생각할수있습니다 

 

클라이언트

클라이언트는 웹에서 정보에 액세스하려는 사용자입니다.

클라이언트는 API를 사용하는 사람이거나 소프트웨어 시스템일수 있습니다.

개발자는 특정 시스템에서 특정시스템의 데이터에 접근하는 프로그램을 작성할수있습니다, 또는 사용자가 특정 웹사이트를 직접 방문할때 브라우저에서 동일한 데이터에 접근할 수 있습니다

REST 아키텍쳐 스타일의 원칙

균일한 인터페이스 

균일한 인터페이스는 모든 RESTful 웹 서비스 디자인의 기본입니다. 이는 서버가 표준 형식으로 정보를 전송함을 나타냅니다. 형식이 지정된 리소스를 REST에서 표현이라고 부릅니다. 이 형식은 서버 애플리케이션에 있는 리소스의 내부 표현과 다를 수 있습니다. 예를 들어, 서버는 데이터를 텍스트로 저장하되, HTML 표현 형식으로 전송할 수 있습니다.

균일한 인터페이스에는 4가지 아키텍처 제약 조건이 있습니다.

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

무상태

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

 

계층화 시스템

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

캐시 가능성

RESTful 웹 서비스는 서버 응답 시간을 개선하기 위해 클라이언트 또는 중개자에 일부 응답을 저장하는 프로세스인 캐싱을 지원합니다. 예를 들어 모든 페이지에 공통 머리글 및 바닥글 이미지가 있는 웹 사이트를 방문한다고 가정해 보겠습니다. 새로운 웹 사이트 페이지를 방문할 때마다 서버는 동일한 이미지를 다시 전송해야 합니다. 이를 피하기 위해 클라이언트는 첫 번째 응답 후에 해당 이미지를 캐싱하거나 저장한 다음 캐시에서 직접 이미지를 사용합니다. RESTful 웹 서비스는 캐시 가능 또는 캐시 불가능으로 정의되는 API 응답을 사용하여 캐싱을 제어합니다

온디맨드 코드

REST 아키텍처 스타일에서 서버는 소프트웨어 프로그래밍 코드를 클라이언트에 전송하여 클라이언트 기능을 일시적으로 확장하거나 사용자 지정할 수 있습니다. 예를 들어, 웹 사이트에서 등록 양식을 작성하면 브라우저는 잘못된 전화번호와 같은 실수를 즉시 강조 표시합니다. 서버에서 전송한 코드로 인해 이 작업을 수행할 수 있습니다

 

리소스

리소스는 다양한 애플리케이션이 클라이언트에게 제공하는 정보입니다.

리소스는 이미지, 동영상, 텍스트, 숫자 또는 모든 유형의 데이터일 수 있습니다.

클라이언트에 리소스를 제공하는 시스템을 서버라고도 합니다.

조직은 API를 사용하여 리소스를 공유하고 보안, 제어 및 인증을 유지하면서 웹 서비스를 제공합니다.

또한 API는 특정 내부 리소스에 접근할수있는 클라이언트를 결정하는데 도움이 됩니다

 

정리

• REST 아키텍쳐의 제약 조건을 준수하는 애플리케이션 프로그래밍 인터페이스를 뜻합니다 
• Rest는 Representational State Transfer ( 대표 상태 전송 ) 의 줄임말입니다
• API 또는 애플리이션 프로그래밍 인터페이스 ( Application Programming Interface) 는 애플리케이션 소프트웨어를 구축하고 통합하는 정의 및 프로트콜 세트입니다 .
• 때때로 API는 정보 제공자와 정보 사용자 간의 계약으로 지칭되며 소비자에게 필요한 콘텐츠와( 호출 )와 생산자에게 필요한 콘텐츠 ( 응답 ) 을 구성합니다

REST ful API 를 사용하면 어떤 이점이 있는가?

 

확장성

REST API를 구현하는 시스템은 REST가 클라이언트 - 서버 사용호 작용을 최적화 하기 떄문에 효율적으로 크기 조정을 할 수 있습니다

무상태는 서버가 과거 클라이너트 요청 정보를 유지할 필요가 없기 떄문에 서버 로드를 제거합니다 

잘 괸리된 캐싱은 일부 클라이언트 - 서버 상호작용을 부분적으로 또는 완전히 제거합니다

이러한 모든 기능은 성능을 저하시키는 통신 병목 현상을 일으키지 않으면서 확장성을 지원합니다 

 

유연성

RESTful 웹 서비스는 완전한 클라이언트 - 서버 분리를 지원합니다 

각 부분이 독립적으로 발전할 수 있도록 다양한 서버 구성 요소를 단순화하고 분리합니다.

서버 애프리케이션의 플랫폼 또는 기술 변경은 클라이언트 애플리케이션에 영향을 주지 않습니다 .

애플맄이션 함수를 계층화 하는 기능은 유연성을 더욱 향상시킵니다

이로인해 개발자는 애플리케이션 로직을 다시 작성하지 않고도 데이터베이스 계층을 변경할 수 있습니다.

독립성

REST API는 사용되는 기술과 독립적입니다.

API 설계에 영향을 주지 않고 다양한 프로그래밍 언어로 클라이언트 및 서버 애플리케이션을 모두 작성할 수 있습니다,

또한 통신에 영향을 주지않고 양쪽의 기본 기술을 변경할 수 있습니다.

 

리차드슨의 REST 성숙도 모델의 구조화

 

RESTfult API 의 호출에 대한 일반 단계

1. 클라이언트가 서버에 요청을 전송합니다 , 클라이언트가 API문서에 따라 서버가 이해하는 방식으로 요청 형식을 지정합니다
2. 서버가 클라이언트를 인증하고 해당 요청을 수행할 수 있는 권한이 클라이언트에 있는지 확인합니다
3. 서버가 요청을 수신하고 내부적으로 처리합니다
4. 서버가 클라이언트에 응답을 반환합니다 , 응답에는 요청이 성공했는지 여부를 클라이언트에 알려주는 정보가 포함됩니다 , 응답에는 클라이언트가 요청한 모든 정보도 포함됩니다 

RESTful API 클라이언트 요청에 포함되있는 주요 구성요소 

 

고유 리소스 식별자

서버는 고유한 리소스 식별자로 각 리소스를 식별합니다

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 세부정보를 지정하는 경로 파라미터.
• 리소스에 대한 추가 정보를 요청하는 쿼리 파라미터.
• 클라이언트를 빠르게 인증하는 쿠키 파라미터.

RESTfult API 의 응답

상태 표시줄

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

1xx : 요청을 받았으며 프로세스를 계속한다

2xx : 요청을 성공적으로 받았으며 인식했고 수용하였다

3xx ( 리다이렉션 ) : 요청 완료를 위해 추가 작업 조치가 필요하다.

4xx ( 클라이언트 오류 ) : 요청의 문법이 잘못되었거나 요청을 처리할 수 없다

5xx ( 서버 오류 ) : 서버가 명백히 유효한 요청에 대해 충족을 실패했다

 

참고

https://ko.wikipedia.org/wiki/HTTP_%EC%83%81%ED%83%9C_%EC%BD%94%EB%93%9C

HTTP 상태 코드 - 위키백과, 우리 모두의 백과사전