상세 컨텐츠

본문 제목

[제133회(1교시)]1. REST API(REpresentational State Transfer Application Programming Interface)에 대하여 설명하시오.

정보관리기술사

by 이거인 2024. 6. 5. 18:33

본문

반응형

REST API(REpresentational State Transfer Application Programming Interface)

 

API란?

  • 응용 프로그램에서 사용할 수 있도록, 운영체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스이다.
  • API는 Application Programming Interface의 약자로, 소프트웨어간의 응답과 요청을 통한 데이터 통신을 위한 방법과 규칙을 의미한다. API는 OS에서도 제공 (e.g. Windows API) 할 수 있고, 프로그래밍 언어 (e.g. Java API) 에서도 제공할 수 있고, 웹 애플리케이션 (e.g. Facebook API) 에서도 제공할 수 있다.API는 주로 서버와 클라이언트 관점에서 설명된다. 클라이언트는 요청을 보내고, 서버는 요청에 응답한다. 웹 API는 SOAP API, RPC API, Websocket API, REST API등이 있는데 이 문서에서는 REST API 에 대해서 다룬다.
  • 웹 프로그래밍 맥락에서는 주로 웹 애플리케이션에서 제공하는 API를 주로 의미한다. 앞으로 이 포스팅에서 API라고 부르는 것은 웹 프로그래밍 맥락에서의 웹 API를 의미한다.

  • API는 무엇을 의미하나요?

    API는 Application Programming Interface(애플리케이션 프로그램 인터페이스)의 줄임말입니다. API의 맥락에서 애플리케이션이라는 단어는 고유한 기능을 가진 모든 소프트웨어를 나타냅니다. 인터페이스는 두 애플리케이션 간의 서비스 계약이라고 할 수 있습니다. 이 계약은 요청과 응답을 사용하여 두 애플리케이션이 서로 통신하는 방법을 정의합니다. API 문서에는 개발자가 이러한 요청과 응답을 구성하는 방법에 대한 정보가 들어 있습니다.

    API는 어떻게 작동하나요?

    API 아키텍처는 일반적으로 클라이언트와 서버 측면에서 설명됩니다. 요청을 보내는 애플리케이션을 클라이언트라고 하고 응답을 보내는 애플리케이션을 서버라고 합니다. 따라서 날씨 예에서 기상청의 날씨 데이터베이스는 서버이고 모바일 앱은 클라이언트입니다. 

    API가 생성된 시기와 이유에 따라 API는 네 가지 방식으로 작동할 수 있습니다.

    SOAP API 

    이 API는 단순 객체 접근 프로토콜을 사용합니다. 클라이언트와 서버는 XML을 사용하여 메시지를 교환합니다. 과거에 더 많이 사용되었으며 유연성이 떨어지는 API입니다.

    RPC API

    이 API를 원격 프로시저 호출이라고 합니다. 클라이언트가 서버에서 함수나 프로시저를 완료하면 서버가 출력을 클라이언트로 다시 전송합니다.

    Websocket API

    Websocket API는 JSON 객체를 사용하여 데이터를 전달하는 또 다른 최신 웹 API 개발입니다. WebSocket API는 클라이언트 앱과 서버 간의 양방향 통신을 지원합니다. 서버가 연결된 클라이언트에 콜백 메시지를 전송할 수 있어 REST API보다 효율적입니다.

    REST API

    오늘날 웹에서 볼 수 있는 가장 많이 사용되고 유연한 API입니다. 클라이언트가 서버에 요청을 데이터로 전송합니다. 서버가 이 클라이언트 입력을 사용하여 내부 함수를 시작하고 출력 데이터를 다시 클라이언트에 반환합니다. 아래에서 REST API에 대해 더 자세히 살펴보겠습니다.

REST란?

    • 웹에 존재하는 모든 자원(이미지, 동영상 등등)에 고유한 URI를 부여해 활용하는 것으로 자원을 정의하고 자원에 대한 주소를 지정하는 방법론이다.
    • 비슷한 말인 RESTful은 이런 형식을 따른 시스템이다.
    • REST는 Representational State Transfer의 줄임말입니다. REST는 클라이언트가 서버 데이터에 액세스하는 데 사용할 수 있는 GET, PUT, DELETE 등의 함수 집합을 정의합니다. 클라이언트와 서버는 HTTP를 사용하여 데이터를 교환합니다.
  • Representational State Transfer(REST)는 API 작동 방식에 대한 조건을 부과하는 소프트웨어 아키텍처입니다. REST는 처음에 인터넷과 같은 복잡한 네트워크에서 통신을 관리하기 위한 지침으로 만들어졌습니다. REST 기반 아키텍처를 사용하여 대규모의 고성능 통신을 안정적으로 지원할 수 있습니다. 쉽게 구현하고 수정할 수 있어 모든 API 시스템을 파악하고 여러 플랫폼에서 사용할 수 있습니다.
  • API 개발자는 여러 아키텍처를 사용하여 API를 설계할 수 있습니다. REST 아키텍처 스타일을 따르는 API를 REST API라고 합니다. REST 아키텍처를 구현하는 웹 서비스를 RESTful 웹 서비스라고 합니다. RESTful API라는 용어는 일반적으로 RESTful 웹 API를 나타냅니다. 하지만 REST API와 RESTful API라는 용어는 같은 의미로 사용할 수 있습니다.

REST API란?

    • REST(Representational State Transfer) 아키텍처 스타일의 설계 원칙을 준수하는 API(애플리케이션프로그래밍 인터페이스)입니다. REST API는 애플리케이션을 통합하고 마이크로서비스 아키텍처의 구성 요소를 연결하는 유연하고 가벼운 방법을 제공합니다.
  • REST API는 Representaional State Transfer API의 약자로써, REST 아키텍처의 제약 조건을 준수하는 API 를 의미한다. 이 REST 제약 조건을 잘 준수함을 RESTful 하다고 표현한다.
  • 그렇다면, REST는 무엇일까? REST는 표준 혹은 프로토콜 같은 것이 아니라, 일반적으로 통용되는 규약이다. 따라서 아래의 내용은 정답이 아니라 일반적으로 권고되는 규칙이란 점을 참고하자.
  • REST는 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에 웹의 장점을 최대한 활용하는 아키텍처이다. 또한 REST API 는 Stateless 하게 동작한다. 각 HTTP 요청은 서로 연관되지 않고 독립적이어야 한다. 따라서 요청과 요청 사이에 일시적으로 저장되는 상태가 없어야한다.
  • REST API의 주된 특징은 무상태입니다. 무상태는 서버가 요청 간에 클라이언트 데이터를 저장하지 않음을 의미합니다. 서버에 대한 클라이언트 요청은 웹 사이트를 방문하기 위해 브라우저에 입력하는 URL과 유사합니다. 서버의 응답은 웹 페이지의 일반적인 그래픽 렌더링이 없는 일반 데이터입니다.
  • RESTful API는 두 컴퓨터 시스템이 인터넷을 통해 정보를 안전하게 교환하기 위해 사용하는 인터페이스입니다. 대부분의 비즈니스 애플리케이션은 다양한 태스크를 수행하기 위해 다른 내부 애플리케이션 및 서드 파티 애플리케이션과 통신해야 합니다. 예를 들어 월간 급여 명세서를 생성하려면 인보이스 발행을 자동화하고 내부의 근무 시간 기록 애플리케이션과 통신하기 위해 내부 계정 시스템이 데이터를 고객의 뱅킹 시스템과 공유해야 합니다. RESTful API는 안전하고 신뢰할 수 있으며 효율적인 소프트웨어 통신 표준을 따르므로 이러한 정보 교환을 지원합니다.

REST 구성요소

  • 자원 ( Resource ) : URI - 모든 자원은 고유한 ID를 가지고 ID는 서버에 존재하고 클라이언트는 각 자원의 상태를 조작하기 위해 요청을 보낸다.
  • 자원에 대한 행위 ( Verb ) : HTTP Method - 클라이언트는 URI를 이용해 자원을 지정하고 자원을 조작하기 위해 Method를 사용한다. HTTP 프로토콜에서는 GET, POST, PUT, DELETE 같은 Method를 제공한다.
  • 자원에 대한 행위의 내용 ( Representations ) - 클라이언트가 서버로 요청을 보냈을 때 서버가 응답으로 보내주는 자원의 상태를 Representation이라고 한다. REST에서 하나의 자원은 JSON, XML, TEXT, RSS 등 여러 형태의 Representation으로 나타낼 수 있다.

보통 CRUD에서 조회는 GET, 등록은 POST, 수정은 PUT, 삭제는 DELETE를 이용한다.

( CRUD는 대부분의 컴퓨터 소프트웨어가 가지는 기본적인 데이터 처리 기능인 Create, Read , Update, Delete를 묶어서 일컫는 말이다. )

 

(3) 구성요소를 적자.

REST API는 일반적으로 다음과 같은 요소로 구성됩니다.

  • 자원 (Resource)
    • 자원은 URI를 통해 고유하게 식별됩니다. 예를 들어, 사용자 자원은 http://example.com/users와 같은 형태의 URI를 가질 수 있습니다.
  • HTTP 메서드
    • 자원에 대한 CRUD(Create, Read, Update, Delete) 작업은 HTTP 메서드를 사용하여 수행됩니다:
      • GET: 자원의 상태를 조회합니다.
      • POST: 새로운 자원을 생성합니다.
      • PUT: 자원의 상태를 업데이트합니다.
      • DELETE: 자원을 삭제합니다.
  • HTTP 상태 코드
    • 서버는 요청에 대한 응답으로 상태 코드를 반환하여 요청의 성공 또는 실패 여부를 나타냅니다. 예를 들어:
      • 200 OK: 요청이 성공적으로 처리되었습니다.
      • 201 Created: 새로운 자원이 성공적으로 생성되었습니다.
      • 400 Bad Request: 잘못된 요청입니다.
      • 404 Not Found: 요청한 자원을 찾을 수 없습니다.
      • 500 Internal Server Error: 서버에 오류가 발생했습니다.
  • 헤더 및 본문
    • 요청과 응답은 헤더와 본문을 가질 수 있습니다. 헤더에는 메타데이터(예: 인증 정보, 콘텐츠 유형 등)가 포함되고, 본문에는 실제 데이터가 포함됩니다.
  •  

리소스 중심 디자인

그리고 REST API는 리소스 중심으로 디자인 된다. 즉, REST API는 비즈니스 엔티티에 집중해야한다. 만드는 서비스가 이커머스라면 비즈니스 엔티티는 고객, 주문, 상품 등이 될 것이다.

리소스는 각각을 고유하게 식별하는 URI가 존재한다. 예를 들어 어떤 블로그 서비스의 특정 포스트 리소스는 아래와 같은 URI로 표현할 수 있다.

https://some-blog-service.com/posts/1

또한 많은 REST API가 요청과 응답의 형식으로 JSON을 채택한다. 예를들어 위 요청에 대한 응답은 아래와 같을 수 있다.

{
  "postId": 1,
  "title": "REST API가 뭘까?",
  "content": "REST API는 Representational Sta..."
}

리소스를 표현할 때 실제 저장된 데이터를 그대로 표현하려하지 않아도 된다. 포스팅이라는 리소스는 실제 관계형 데이터베이스에서는 여러 테이블이 Join 되어 표현되겠지만 (예를 들어 Posting 테이블과 Comment 테이블), 이 내부 구현을 그대로 리소스로 표현하지 않고, 포스팅이라는 단일 엔티티로 표현하자.

 

REST 의 특징

  • 클라이언트 / 서버 구조 (Client-Server) - 자원이 있는 Server , 자원을 요청하는 Client의 구조를 가진다.
  • 무상태 (Stateless) - HTTP는 Stateless 프로토콜 이므로 REST 역시 무상태성을 가진다. 클라이언트의 Context 를 서버에 저장하지 않는다.
  • 캐시 처리 가능 (Cacheable) - 웹 표준 HTTP 프로토콜을 그대로 사용하므로 , 웹에서 사용하는 기존의 인프라를 그대로 활용 가능하다.
  • 계층화 - API 서버는 순수 비즈니스 로직을 수행하고 그 앞단에 사용자 인증 , 암호화 , 로드밸런싱 등을 하는 계층을 추가하여 구조상의 유연성을 줄 수 있다.
  • 인터페이스 일관성(Uniform Interface) - URI로 지정한 자원에 대한 조작을 통일되고 한정적인 인터페이스로 수행한다. HTTP 표준에만 따른다면 모든 플랫폼에 사용이 가능하다.
  • 자체 표현 구조 - 동사(Method) + 명사(URI) 로 이루어져있어 어떤 메서드에 무슨 행위를 하는지 알 수 있으며 REST API 자체가 매우 쉬워서 API 메세지 자체만 보고도 API를 이해할 수 있다

REST API 의 기본 특징은 아래와 같습니다. 

1. 클라이언트-서버 구조

  • 클라이언트와 서버가 명확히 분리되어 있습니다. 클라이언트는 사용자 인터페이스와 관련된 작업을 수행하고, 서버는 데이터 저장 및 처리를 담당합니다.

2. 무상태성 (Stateless)

  • 각 요청은 독립적이며, 서버는 클라이언트의 상태를 저장하지 않습니다. 모든 요청에는 필요한 모든 정보가 포함되어야 합니다.

3. 캐시 가능 (Cacheable)

  • 응답은 캐시 가능해야 합니다. HTTP 헤더를 사용하여 응답이 캐시될 수 있는지 여부를 명시할 수 있습니다.

4. 일관된 인터페이스 (Uniform Interface)

  • API는 일관된 방법으로 자원에 접근할 수 있도록 설계되어야 합니다. 이를 위해 REST는 몇 가지 하위 제약을 정의합니다:
    • 자원 식별 (Resource Identification): URI를 사용하여 자원을 식별합니다.
    • 자원 표현 (Resource Representation): 자원은 XML, JSON 등 다양한 형식으로 표현될 수 있습니다.
    • 자원 조작 (Resource Manipulation): HTTP 메서드(GET, POST, PUT, DELETE 등)를 사용하여 자원을 조작합니다.
    • 자기 설명적 메시지 (Self-descriptive Messages): 각 메시지는 자신을 설명하는 정보를 포함해야 합니다.
    • 하이퍼미디어에 의한 애플리케이션 상태 엔진 (HATEOAS): 클라이언트는 서버가 제공하는 링크를 통해 애플리케이션의 상태를 변경할 수 있어야 합니다.

5. 계층화 시스템 (Layered System)

  • 클라이언트는 중간 서버를 통해서도 서버에 접근할 수 있으며, 중간 서버는 로드 밸런싱, 캐싱 등의 기능을 수행할 수 있습니다.

REST의 장단점

장점

  1. 쉬운 사용 - HTTP 프로토콜 인프라를 그대로 사용하므로 별도의 인프라를 구축할 필요가 없다.
  2. 클라이언트-서버 역할의 명확한 분리 - 클라이언트는 REST API를 통해 서버와 정보를 주고받는다. REST의 특징인 Stateless에 따라 서버는 클라이언트의 Context를 유지할 필요가 없다.
  3. 특정 데이터 표현을 사용가능 - REST API는 헤더 부분에 URI 처리 메소드를 명시하고 필요한 실제 데이터를 ‘body’에 표현할 수 있도록 분리시켰다. JSON , XML 등 원하는 Representation 언어로 사용 가능하다.
  • REST API를 사용하면 어떤 이점이 있나요? REST API는 다음과 같은 네 가지 주요 이점을 제공합니다.1. 통합 2. 혁신 3. 확장4. 유지 관리의 용이성
  • API는 두 시스템 간의 게이트웨이 역할을 합니다. API가 영향을 받지 않도록 각 시스템은 내부적으로 변경해야 합니다. 이렇게 하면 한 시스템의 향후 코드 변경이 다른 시스템에 영향을 미치지 않습니다.
  • API는 기업이 다양한 플랫폼에서 고객의 요구 사항을 충족할 수 있는 고유한 기회를 제공합니다. 예를 들어 지도 API를 사용하면 웹 사이트, Android, iOS 등을 통해 지도 정보를 통합할 수 있습니다. 어느 기업이나 무료 또는 유료 API를 사용하여 내부 데이터베이스에 유사한 액세스 권한을 부여할 수 있습니다.
  • 새로운 앱의 등장으로 전체 산업이 바뀔 수 있습니다. 기업은 신속하게 대응하고 혁신적인 서비스의 신속한 배포를 지원해야 합니다. 전체 코드를 다시 작성할 필요 없이 API 수준에서 변경하여 이를 수행할 수 있습니다.
  • API는 새로운 애플리케이션을 기존 소프트웨어 시스템과 통합하는 데 사용됩니다. 그러면 각 기능을 처음부터 작성할 필요가 없기 때문에 개발 속도가 빨라집니다. API를 사용하여 기존 코드를 활용할 수 있습니다.

단점

  1. 메소드의 한계 - REST는 HTTP 메소드를 이용하여 URI를 표현한다. 이러한 표현은 쉬운 사용이 가능하다는 장점이 있지만 반대로 메소드 형태가 제한적인 단점이 있다.
  2. 표준이 없음 - REST는 설계 가이드 일 뿐이지 표준이 아니다. 명확한 표준이 없다.

HTTP 메서드에 따른 API 작업 정의

RESTful 하게 구현된 REST API는 HTTP 메서드를 아래와 같은 행위에 맞도록 디자인한다.

GET

명시된 URI에 해당하는 리소스를 가져온다.

일반적으로 HTTP 상태 코드 200을 반환하고, 리소스를 찾을 수 없을 경우 404를 반환한다. 요청은 정상적으로 처리되었지만, 보여줄 데이터가 없을 경우 (예를 들어 검색결과가 없을 경우) 204를 반환한다.

POST

명시된 URI에 새 리소스를 생성한다.

리소스가 성공적으로 생성되었을 경우 HTTP 상태 코드 201을 반환하고, 반환할 결과가 딱히 없을 경우 204를 반환한다. 리소스를 생성할 때 클라이언트가 잘못된 요청을 전송했을 경우 (예를 들어 양수여야 하는 필드를 음수로 전달한 경우) 400을 반환한다.

PUT

명시된 URI를 새 리소스로 대체하거나, 없다면 새로운 리소스를 생성한다.

PATCH

명시된 URI에 해당하는 리소스의 일부분을 업데이트한다.

PATCH는 앞서 이야기한 PUT과 비슷해 보이는데, 어떤 차이점이 존재할까? PUT은 리소스의 모든 정보를 업데이트 한다. 즉 새로운 리소스로 대체한다. 하지만, PATCH는 리소스의 일부분만을 업데이트 한다는 차이점이 존재한다.

DELETE

지정된 URI에 해당하는 리소스를 제거한다. 삭제가 성공하면 응답으로 빈 본문을 반환하고, HTTP 상태 코드 204를 반환한다. 존재하지 않는 리소스에 요청한 경우 404를 반환한다.

PUT vs PATCH

PUT

  • 리소스의 모든 것을 업데이트 하기 때문에 보내지 않은 속성 값들에 대해서는 null 값으로 변경한다.

PATCH

  • 리소스의 일부를 업데이트 하기 때문에 요청에 포함된 부분만 변경된다.

REST 관점에서의 HTTP Status Code

REST API는 클라이언트의 요청에 대한 처리 결과를 HTTP Status Code를 이용해 표현할 수 있다. 단, 모든 HTTP 상태 코드를 나열할 수는 없으므로, 자주 사용하는 상태 코드와 그에 대한 설명, 용도를 간단히 정리해본다.

2XX - 성공 응답

클라이언트의 요청이 유효하고, 서버도 그 요청을 성공적으로 처리했을 때 반환하면 적절한 상태코드이다.

  • 200 (OK) : 클라이언트의 요청을 서버가 정상적으로 처리했음.
  • 201 (CREATE) : 클라이언트의 요청을 서버가 정상적으로 처리했으며, 새로운 리소스가 생성되었음.
  • 202 (Accepted) : 클라이언트의 요청을 서버가 정상적으로 수신했지만, 아직 요청을 완료하지 못했음. 서버의 작업이 오래걸릴 경우에 비동기적으로 요청을 처리하기 위해 사용하는 응답 코드이다.
  • 204 (No Content) : 클라이언트의 요청을 서버가 정상적으로 처리했지만, 응답할만한 데이터가 없음. DELETE 등의 메소드를 사용하여 리소스가 제거되었을 경우, PUT 등의 메소드로 리소스를 업데이트 하였으나 변화가 없을 경우 반환하면 적절한 상태코드이다.

성공에 대한 응답을 모두 200 으로 처리해도 큰 문제는 없지만, 클라이언트에게 자세한 정보를 제공하기 위해서는 조금 더 적절한 상태 코드를 반환하는 것이 좋다.

4XX - 실패 응답

클라이언트의 요청이 유효하지 않을 경우 반환하는 상태코드이다.

  • 400 (Bad Request) : 필수 필드 누락, 유효성 검사 실패 등 클라이언트의 요청이 유효하지 않을 경우 반환하는 실패 응답. 400 응답 코드와 함께 에러의 이유를 함께 Body로 명시해주는 것이 좋다.
  • 401 (Unauthorized) : 인증정보(로그인 등)이 필요한 요청인데 불구하고, 인증정보가 존재하지 않은 경우에 반환하는 실패 응답. 이름만 보면 Authorize (인가) 관련 응답인 것 같지만, Authenticate (인증) 에 관한 응답이라고 한다.
  • 403 (Forbidden) : 인증된(Authenticated) 클라이언트가 권한이 없는(Unauthorized) 경우 반환하는 실패 응답. 401 과 그 용도를 혼동하지 않도록 주의하자.
  • 404 (Not Found) : 클라이언트가 요청한 자원이 존재하지 않을 경우 반환하는 실패 응답.
  • 405 (Method Not Allowed) : URI에 해당하는 자원은 존재하지만, 요청한 메소드를 허용하지 않을 경우 반환하는 실패 응답. 예를 들어 GET 메소드로 접근할 수 있는 자원이지만 PUT 으로 수정은 허용하지 않을 경우에 반환하기 적절한 상태코드이다.
  • 409 (Conflict) : 클라이언트의 요청이 서버의 상태와 충돌이 발생한 경우 반환하는 실패 응답. 충돌의 의미가 굉장히 모호하여 명확한 기준을 세우는 것이 중요할 것 같다.
  • 429 (Too Many Requests) : 클라이언트가 단기간에 너무 많은 요청을 보냈을 경우 응답하는 실패 코드.

인증(Authenticate)은 클라이언트 자신이 주장하는 사용자와 클라이언트가 실제 같은 사용자인지 검증하는 로그인 같은 과정을 의미한다. 반면, 인가(Authorized)는 인증이 된 이후 클라이언트가 해당 요청에 대한 권한이 있는지 검사하는 것을 의미한다.

5XX - 서버 에러

클라이언트의 요청은 유효하지만, 그 작업을 수행하는데 있어 서버에서 오류가 발생했을 경우 반환하기 적합한 코드이다. 정말 예상치 못한 경우를 제외하고는 클라이언트에게 5XX 에러와 그 내용을 보여줘서는 안된다.

참고 - https://ko.wikipedia.org/wiki/API // https://medium.com/@hckcksrl/rest%EB%9E%80-c602c3324196 // https://poiemaweb.com/js-rest-api // https://programmer93.tistory.com/39 

// REST(Representational State Transfer) API (hudi.blog) // API란 무엇인가요? - 애플리케이션 프로그래밍 인터페이스 설명 - AWS (amazon.com) // 

REST API ( Representational State Transfer Application Programming Interface ) (velog.io)

 

 

REST API 작동 방식

REST API는 HTTP 요청을 통해 통신하여 리소스 내에서 레코드를 생성하고 읽기, 업데이트 및 삭제(CRUD라고도 함)와 같은 표준 데이터베이스 기능을 수행합니다.

예를 들어 REST API는 GET 요청을 사용하여 레코드를 검색합니다. POST 요청은 새 레코드를 생성합니다. PUT 요청은 레코드를 업데이트하고 DELETE 요청은 레코드를 삭제합니다. API 호출에는 모든 HTTP 방식를 사용할 수 있습니다. 잘 설계된 REST API는 HTTP 기능이 내장된 웹 브라우저에서 실행되는 웹 사이트와 유사합니다.

특정 순간 또는 타임스탬프의 리소스 상태를 리소스 표현이라고 합니다. 이 정보는 JSON(JavaScript Object Notation), HTML, XLT, Python, PHP 또는 일반 텍스트를 포함한 거의 모든 형식으로 클라이언트에 전달될 수 있습니다. JSON은 사람과 기계 모두 읽을 수 있고 프로그래밍 언어에 구애받지 않기 때문에 널리 사용됩니다.

요청 헤더 및 매개 변수는 메타데이터, 권한 부여, URI(Uniform Resource Identifier), 캐싱, 쿠키 등과 같은 중요한 식별자 정보를 포함하기 때문에 REST API 호출에서도 중요합니다. 요청 헤더 및 응답 헤더는 기존 HTTP 상태 코드와 함께 잘 설계된 REST API 내에서 사용됩니다.

RESTful API는 어떻게 작동하나요?

RESTful API의 기본 기능은 인터넷 브라우징과 동일합니다. 클라이언트는 리소스가 필요할 때 API를 사용하여 서버에 접속합니다. API 개발자는 서버 애플리케이션 API 문서에서 클라이언트가 REST API를 어떻게 사용해야 하는지 설명합니다. 다음은 모든 REST API 호출에 대한 일반 단계입니다.

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

REST API 요청 및 응답 세부 정보는 API 개발자가 API를 설계하는 방식에 따라 약간씩 다릅니다.

 

 

 

 

 

4) 고려사항을 적자.

REST API를 설계할 때 다음 사항을 고려해야 합니다

  • 자원 모델링
    • 자원을 식별하고 URI 구조를 설계합니다.
  • HTTP 메서드 사용
    • 각 작업에 적합한 HTTP 메서드를 선택합니다.
  • 상태 코드
    • 적절한 HTTP 상태 코드를 반환하여 클라이언트가 요청의 결과를 이해할 수 있도록 합니다.
  • 보안
    • HTTPS를 사용하여 데이터 전송을 암호화하고, 인증 및 권한 부여 메커니즘을 구현합니다.
  • 버전 관리
    • API의 변경 사항을 관리하기 위해 버전 관리를 도입합니다. 예를 들어, http://example.com/v1/users와 같이 URI에 버전을 포함할 수 있습니다.

출처: https://idealist.tistory.com/148 [가슴이 웅장해지는 모든것:티스토리]

 

REST 설계 원칙

가장 기본적인 수준에서 API는 애플리케이션이나 서비스가 다른 애플리케이션이나 서비스 내의 리소스에 액세스할 수 있도록 하는 메커니즘입니다. 리소스에 액세스하는 애플리케이션이나 서비스가 클라이언트이고 리소스를 포함하는 애플리케이션이나 서비스는 서버입니다. SOAP 또는 XML-RPC와 같은 일부 API는 개발자에게 엄격한 프레임워크를 적용합니다. 그러나 개발자는 거의 모든 프로그래밍 언어를 사용하여 REST API를 개발할 수 있으며 다양한 데이터 형식을 지원합니다. 유일한 요구 사항은 아키텍처 제약 조건이라고도 하는 다음 6가지 REST 설계 원칙을 준수해야 한다는 것입니다.
 
균일한 인터페이스

동일한 리소스에 대한 모든 API 요청은 요청의 출처에 관계없이 동일하게 표시되어야 합니다. REST API는 사용자의 이름 또는 이메일 주소와 같은 동일한 데이터가 하나의 URI(Uniform Resource Identifier)에만 속하도록 해야 합니다. 리소스가 너무 커서는 안 되며 클라이언트가 필요로 할 수 있는 모든 정보를 포함해야 합니다.

 

클라이언트-서버 분리

REST API 설계에서 클라이언트 및 서버 애플리케이션은 서로 완전히 독립적이어야 합니다. 클라이언트 애플리케이션이 알아야 하는 유일한 정보는 요청된 리소스의 URI입니다. 서버 애플리케이션과 다른 방법으로 통신할 수 없습니다. 마찬가지로 서버 애플리케이션은 HTTP를 통해 요청된 데이터에 클라이언트 애플리케이션을 전달하는 것 외에는 클라이언트 애플리케이션을 수정해서는 안 됩니다.

 

무상태

REST API는 무상태성이기 때문에 각 요청에는 처리에 필요한 모든 정보가 포함되어야 합니다. 즉, REST API에는 서버 측 세션이 필요하지 않다는 의미입니다. 서버 애플리케이션은 클라이언트 요청과 관련된 데이터를 저장할 수 없습니다.

 

캐시 가능성

가능한 경우 클라이언트나 서버 측에서 리소스를 캐시할 수 있어야 합니다. 서버 응답에는 전달된 리소스에 대해 캐싱이 허용되는지 여부에 대한 정보도 포함되어야 합니다. 목표는 클라이언트 측의 성능을 향상시키는 동시에 서버 측의 확장성을 높이는 것입니다.

 

계층화된 시스템 아키텍처

REST API에서는 호출과 응답이 서로 다른 계층을 거칩니다. 일반적으로 클라이언트와 서버 애플리케이션이 서로 직접 연결된다고 가정하지 않습니다. 통신 루프에는 다양한 중개자가 있을 수 있습니다. REST API는 클라이언트나 서버가 최종 애플리케이션과 통신하는지 중개자와 통신하는지 알 수 없도록 설계해야 합니다.

 

코드 온디맨드(선택 사항)

REST API는 일반적으로 정적 리소스를 전송하지만 경우에 따라 응답에 실행 코드(예: Java 애플릿)가 포함될 수도 있습니다. 이러한 경우 코드는 온디맨드 방식으로만 실행되어야 합니다.

 

좋은 URI 설계를 위한 여러가지 규칙

  • URI의 맨 뒤에는 / 가 붙지 않는다.
  • 즉, /posts 와 /posts/ 는 동일한 리소스를 가리킨다.
  • 계층적 관계를 나타낼 때 / 를 사용한다.
  • /posts/1/comments 는 포스팅 컬렉션, 개별 포스팅 개체, 개별 포스팅의 코멘트 컬렉션을 계층적으로 나타낸다.
  • 밑줄(_)을 사용하지 않는다. 대신, 가독성을 위해 하이픈(-) 을 사용한다.
  • /best_posts 대신 /best-posts 로 표현하자.
  • 대소문자를 섞어 쓰지 않고, 소문자만을 사용한다.
  • URI에 파일 확장자를 포함하지 않는다.
  • 행위는 URI에 표기하지 않는다. URI는 동사가 아니라 명사를 기반으로 디자인 해야한다. 즉, 리소스에 대한 작업이 아니라 대상 리소스를 중심으로 디자인한다.
  • https://some-blog-service.com/posts // 좋음
https://some-blog-service.com/create-post // 좋지 않음

 

 인증방법: https://aws.amazon.com/ko/what-is/restful-api/#seo-faq-pairs#what-are-restful-api-auth

 REST와 SOAP 비교: REST vs SOAP: 개념, 특징, 차이점, 장단점 이해하기 쉽게 비교 (redhat.com)

 

출처: REST API란 무엇인가요? | IBM

728x90
반응형

관련글 더보기

티스토리툴바