코드스테이츠-부트캠프 [Rest API]

김희목·2024년 3월 30일
REST API코드스테이츠
0

코드스테이츠

목록 보기
43/56

Rest API란?

Rest API란 Representational State Transfer 즉, REST라는 아키텍처 스타일을 따르는 API(Application Programming Interface)입니다.
API 개발자는 REST뿐만 아니라 여러 아키텍처를 사용해 API를 설계할 수 있습니다.

API란?

다른 소프트웨어 시스템과 통신하기 위해 따라야 하는 규칙이나 형식을 정의한 것입니다. API는 서로 다른 애플리케이션 또는 장치가 서로 데이터나 기능을 교환하고 상호 작용할 수 있도록 도와줍니다.

예를 들어, 웹 사이트 혹은 모바일 장치에서 날씨 정보를 보여주기 위해 날씨 서비스의 API에 요청을 보낼 수 있습니다. 또는 영화 예매를 위해 예매 서비스의 API에 요청을 보낼 수 있습니다.

API는 사용자 인터페이스와 달리 컴퓨터나 소프트웨어끼리만 사용되는 인터페이스입니다. 즉, 사용자가 직접 보거나 조작할 수 없고, 개발자가 소프트웨어에 포함해야만 합니다.

REST 아키텍처란?

API의 작동 방식에 대한 조건을 부과하는 소프트웨어 아키텍처로, REST는 처음에 인터넷과 같은 복잡한 네트워크에서 통신을 관리하기 위한 지침으로 만들어졌습니다.

REST 아키텍처의 특징

클라이언트-서버 구조
클라이언트는 서버에 요청을 보내고 서버는 요청에 대한 응답을 보냅니다. 클라이언트와 서버는 독립적으로 개발하고 운영할 수 있습니다.
균일한 인터페이스
서버는 표준화된 형식으로 리소스를 표현하고, 클라이언트는 리소스는 식별하고 조작할 수 있습니다. 리소스는 URI(Uniform Resource Identifier)로 식별되고, HTTP 메서드(GET, POST, PUT, DELETE 등)로 조작됩니다.
서버는 자기 기술적인 메시지와 하이퍼링크를 전송해 클라이언트가 리소스를 적절하게 사용할 수 있도록 합니다.
무 상태성
서버는 클라이언트의 상태 정보를 저장하지 않고, 각 요청은 독립적으로 처리됩니다. 클라이언트는 임의의 순서로 리소스를 요청할 수 있으며 모든 요청은 다른 요청과 분리됩니다. 요청에는 필요한 모든 정보가 포함되어야 합니다.
캐시 가능성
서버는 응답에 캐시 가능 여부를 명시하고, 클라이언트는 캐시 된 응답을 재사용할 수 있습니다. 예를 들어 모든 페이지에 공통 머리글 및 바닥글 이미지가 있는 웹 사이트를 방문할 경우, 해당 웹사이트의 다른 페이지에 방문할 때마다 서버는 동일한 이미지를 다시 전송해야 합니다. 이를 피하고자 클라이언트는 첫 번째 응답 후에 해당 이미지를 캐싱하거나 저장한 다음 캐시에서 직접 이미지를 사용합니다. 이를 통해 성능과 확장성을 향상할 수 있습니다.
코드 온 디맨드(선택 사항)
서버는 필요에 따라 클라이언트로 실행할 수 있는 코드(자바스크립트 등)를 전송하여 클라이언트의 기능을 일시적으로 확장하거나 사용자 지정할 수 있습니다.

Rest API를 사용하는 이유

유연성

  • REST API는 완전한 클라이언트-서버 분리를 지원함으로써 각 부분이 독립적으로 발전할 수 있도록 다양한 서버 구성 요소를 단순화하고 분리합니다. 또한, 서버 애플리케이션의 플랫폼 또는 기술 변경은 클라이언트 애플리케이션에 영향을 주지 않습니다. 이는 서버와 클라이언트 각각에 유연성을 부여할 수 있습니다. 또한, REST API는 다양한 종류의 요청을 처리할 수 있으며 다양한 형식의 데이터를 전송할 수 있는 유연함을 가지고 있습니다.

확장성

  • REST API는 서로 다른 능력을 갖춘 소프트웨어 시스템 간에 통신할 수 있도록 설계되었습니다. REST 아키텍처의 특징 중 하나인 무 상태는 서버가 과거 클라이언트 요청 정보를 유지할 필요가 없기 때문에 서버의 로드를 제거하며 이는 서버가 더 확장될 수 있는 이유가 됩니다. 또한 다른 특징인 잘 관리된 캐싱은 일부 클라이언트-서버 작용을 부분적으로 또는 완전히 제거합니다.
    이러한 모든 기능은 성능을 저하하는 통신 병목 현상을 일으키지 않으면서 확장성을 지원합니다.

독립성

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

Rest API를 요청할 때 필요한 요소

고유 리소스 식별자

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

메서드

  • HTTP를 사용하여 Rest API를 구현합니다. HTTP 메서드는 리소스에 수행해야 하는 작업을 서버에 알려주는 역할을 합니다. 이후 HTTP 메서드에 대해 학습하도록 하겠습니다.

HTTP 헤더

  • 요청 헤더는 클라이언트와 서버 간에 교환되는 메타데이터입니다.

    • 데이터: Rest API 요청에는 HTTP 메서드가 성공적으로 작동하기 위한 데이터가 포함될 수 있습니다.

    • 파라미터: 수행해야 할 작업에 대한 자세한 정보를 서버에 제공하는 파라미터가 포함될 수 있습니다. 다음은 몇 가지 파라미터 유형입니다.

    • 경로 파라미터 - URL 세부 정보를 지정하기 위해 사용합니다.
      예를 들어, 사용자 ID로 사용자를 조회하는 URL /users/{id}의 경우 {id}는 경로 파라미터로서 특정 사용자의 ID를 나타냅니다. 경로 파라미터는 중괄호 {}로 둘러싸여 있으며, API 호출 시에 실제 값으로 대체되어야 합니다. 경로 파라미터는 항상 필수적이므로 required: true를 명시해야 합니다.

    • 쿼리 파라미터 - URL의 끝에 붙어서 요청에 대한 추가적인 정보나 조건을 전달하는 변수를 말합니다. 쿼리 파라미터는 URL과 물음표(?)로 구분되며, 여러 개의 쿼리 파라미터는 앰퍼샌드(&)로 연결됩니다.
      쿼리 파라미터는 리소스의 위치를 나타내는 경로 파라미터와 달리 리소스의 정렬, 페이징, 필터링 등의 작업을 정의합니다. 쿼리 파라미터는 필수적이지 않을 수 있습니다.
      쿼리 파라미터의 예는 다음과 같습니다.

      /users?role=admin : 역할이 admin인 사용자들을 조회하는 API
      /notes?offset=100&limit=50 : 노트들을 100번째부터 50개씩 조회하는 API

Rest API 서버 응답에 포함된 요소

상태 코드

  • 서버가 요청을 처리한 결과를 나타내는 숫자 코드입니다. 상태 코드는 다음과 같은 규칙을 따릅니다.
    • 첫 번째 자리는 상태 코드의 분류를 나타냅니다. 1xx는 정보전달, 2xx는 성공, 3xx는 리 다이렉션, 4xx는 클라이언트 오류, 5xx는 서버 오류를 의미합니다.
    • 두 번째 자리는 상태 코드의 세부 분류를 나타냅니다. 예를 들어, 4xx에서 40x는 일반적인 클라이언트 오류, 41x는 인증 관련 오류를 의미합니다.
    • 세 번째 자리는 상태 코드의 구체적인 의미를 나타냅니다. 예를 들어, 404는 요청한 리소스가 없음, 401은 인증이 필요함을 의미합니다.
  • 상태 코드의 대표적인 예는 다음과 같습니다.
    • 200 - OK 상태코드로 요청이 성공적으로 처리되었음을 의미합니다.
    • 301 - Moved Permanently 상태 코드로 요청한 리소스가 영구적으로 다른 위치로 리 다이렉트 됨을 의미합니다. 새로운 위치는 Location 헤더에 명시됩니다.
    • 400 - Bad Request 상태 코드로 요청이 잘못되었거나 서버가 이해할 수 없음을 의미합니다.
    • 404 - Not Found 상태 코드로 요청한 리소스가 서버에 존재하지 않음을 의미합니다.
    • 500 - Internal Server Error 상태 코드로 서버에게 오류가 발생하여 요청을 처리할 수 없음을 의미합니다.

헤더

  • 서버가 응답에 대한 추가적인 정보나 조건을 전달하는 파라미터입니다. 예를 들어 Content-Type은 응답의 데이터 형식을, Location은 새로 생성된 리소스의 위치를, Set-Cookie는 쿠키를 설정하는 등의 역할을 합니다.

바디(메시지 본문)

  • 서버가 요청에 대한 데이터나 기능을 전달하는 부분입니다. 바디는 JSON, XML, HTML 등의 형식으로 인코딩됩니다. 예를 들어 클라이언트가 Amy라는 사람의 이름과 나이를 요청하면 서버는 다음과 같이 JSON 표현을 반환합니다. { "name": "Amy", "age": 30 }

HTTP 메서드란?

클라이언트가 서버에게 요청할 때 리소스에 대해 수행하고자 하는 행위를 나타내는 방식을 말합니다.

HTTP 메서드의 종류

  • GET

    • 리소스의 표현을 조회하는 메서드입니다. GET 메서드는 서버의 상태를 변경시키지 않으므로 안전하고 멱등합니다. 즉, 여러 번 요청하더라도 결과가 달라지지 않습니다.
    • GET 메서드는 URL에 요청 파라미터를 포함할 수 있으며 요청 파라미터의 예로는 위에서 설명한 쿼리 파라미터나 경로 파라미터 등이 있습니다.

  • POST

    • 새로운 리소스를 생성하거나 기존의 리소스에 데이터를 추가하는 메서드입니다. POST 메서드는 서버의 상태를 변경시킬 수 있으므로 안전하지 않고 멱등하지 않습니다. POST 메서드는 요청 바디에 데이터를 포함할 수 있습니다.

  • PUT

    • 기존의 리소스를 전체적으로 수정하거나 새로운 리소스를 생성하는 메서드입니다.
    • PUT 메서드는 동일한 요청을 여러 번 수행해도 결과가 같으므로 멱등합니다.
    • 하지만 서버의 상태를 변경시킬 수 있으므로 안전하지 않습니다.
    • PUT 메서드는 요청 바디에 데이터를 포함할 수 있습니다.

  • PATCH

    • 기존의 리소스를 부분적으로 수정하는 메서드입니다.
    • PATCH 메서드는 수정할 데이터만 요청 바디에 포함할 수 있습니다.
    • PATCH 메서드는 서버의 상태를 변경시킬 수 있으므로 안전하지 않고, 동일한 요청을 여러 번 수행해도 결과가 같지 않을 수 있으므로 멱등하지 않습니다.

  • DELETE

    • 기존의 리소스를 삭제하는 메서드입니다. DELETE 메서드는 동일한 요청을 여러 번 수행해도 결과가 같으므로 멱등합니다.
    • 하지만 서버의 상태를 변경시킬 수 있으므로 안전하지 않습니다.

  • 이 외에도 HEAD , OPTIONS 등의 HTTP 메서드가 있지만, Rest API에서는 잘 사용되지 않습니다.

profile
김희목
이전 포스트

코드스테이츠-부트캠프 [소프트웨어 개발 방법론]

다음 포스트

코드스테이츠-부트캠프 [React-심화](1)

0개의 댓글