[Web] REST API란 무엇인가?

REST API

> Representational State Transfer 소프트웨어 아키텍처의  종류

분산 시스템에서 네트워크를 통해 서로 통신하는 시스템 간의 상호 운용성을 향상하는 방법을 제공해 준다.

 

디자인 원칙

• 균일한 인터페이스
  • HTTP 표준만 맞다면, 동일한 리소스에 대한 모든 요청은 동일하게 보여준다.
  • 동일한 데이터가 하나의 URI에 속하도록 보장한다.
  • REST API를 구현한다면 어떤 개발 언어나 플랫폼에 종속되지 않고 일관적인 데이터를 받을 수 있다.
• 클라이언트-서버 디커플링
  • 클라이언트와 서버 간의 완전한 독립
  • 클라이언트는 요청된 리소스의 URI만 알아야 한다.
  • 서버는 HTTP 요청 외에는 클라이언트를 수정할 수 없다.
• Stateless
  • 각 요청에서 처리에 필요한 모든 정보를 포함한다.
  • 서버 세션은 불필요하며, 클라이언트 요청과 관련된 데이터를 저장할 수 없다.
• 캐싱
  • 리소스를 클라이언트 또는 서버에 캐싱할 수 있어야 한다.
  • 서버 응답에 전달된 리소스에 대해 캐싱이 허용 여부도 포함되어야 한다.
  • 서버의 확장성과 클라이언트의 성능 향상을 얻는다.
• 계층 구조
  • 호출과 응답은 서로 다른 계층을 통한다.
  • 클라이언트와 서버는 직접 연결된다고 가정하지 않는 것이 좋다.
  • REST API는 앱 또는 중개자와 통신 여부를 클라이언트나 서버가 알 수 없어야 한다.
• 코드 온디맨드
  • 정적 리소스를 전송하지만, 특정한 경우 실행 코드를 포함할 수 있다.
  • 코드는 요청 시에만 실행

구성

• Method

  • POST	CREATE
    GET	SELECT
    PUT	UPDATE
    DELETE	DELETE

• Resource
  • 서비스가 제공하는 데이터 또는 기능
  • 자원은 고유한 URI로 식별된다.
• Representation
  • 클라이언트와 서버 간에 전송되는 자원의 상태
  • JSON 또는 XML

 

특징

간단한 블로그 서비스를 예시로 특징을 나타내자면

• Resource
  • 게시물: 제목과 내용
  • 댓글: 작성자와 내용
• Representation

게시물
{
    "id": 1,
    "title": "REST API",
    "content": "REST API는 JSON과 XML 형태로 표현될 수 있다."
}

댓글
{
    "id": 1,
    "author": "Haessae0",
    "content": "LGTM"
}

• URI
  • 게시물: '/posts/{postId}
    • postId는 게시물의 고유 식별자이다.
  • 댓글: '/posts/{postId}/comments/{commentId}
    • postId의 commentId로 고유 식별한다.
• Method

  • 게시물 POST	/posts
    게시물 GET	/posts/{postId}
    게시물 PUT	/posts/{postId}
    게시물 DELETE	/posts/{postId}
    댓글 POST	/posts/{postId}/comments
    댓글 GET	/posts/{postId}/comments/{commentId}
    댓글 PUT	/posts/{postId}/comments/{commentId}
    댓글 DELETE	/posts/{postId}/comments/{commentId}

• Self-descriptive Messages
  • HTTP 요청과 응답은 각각의 목적과 처리 방식에 대한 정보를 명시적으로 제공
• HATEOAS (Hypermedia as the Engine of Application State)
  • 게시물을 조회할 때 서버는 해당 게시물에 대한 하이퍼링크를 함께 제공하여 클라이언트가 해당 자원에 대한 다른 작업을 수행할 수 있도록 제공한다.

출처

https://www.ibm.com/kr-ko/topics/rest-apis