REST API 란?

Bluewind·2022년 4월 23일
REST
0

Spring

목록 보기
3/5
post-thumbnail
post-custom-banner

사전 개념

API란?

API(Application Programming Interface)는 어플리케이션 소프트웨어를 구축하고 통합하는 정의 및 프로토콜 세트입니다.

예를 들어, 기상청 서버가 있습니다. 이 기상청의 날씨 서비스용 API를 사용하는 다양한 웹사이트나 앱들이 이 기상청 서버로 부터 실시간으로 날씨 정보를 요청하여 데이터를 받아갈 수 있습니다.

웹사이트나 웹은 지정된 형식을 통하여 날짜, 지역등을 넣어서 요청하면, 기상청 서버는 최고 기온, 최저 기온으로 구성된 응답으로 답하도록 지정할 수 있는 것입니다.

REST API의 역사

  • 1991년 '인터넷 상에서 어떻게 정보를 공유할 것인가'에 대한 답으로, 정보들을 하이퍼텍스트로 연결하여 HTML으로 표현하고, URI로 식별하고, HTTP로 전송하는 방법을 만듭니다.
  • 그래서 이미 널리 쓰여지고 있던 프로토콜인 HTTP를 기존의 HTTP를 사용하고 있는 웹들과 부딪치지 않으면서 업그레이드 시킬 방법을 모색합니다. 그래서 나온것이 Roy T. Fielding의 HTTP Object Model입니다.
  • 1998년에 Roy T. Fielding은 이 HTTP Object Model을 REST 라는 이름으로 변경하여 발표하게 됩니다.
  • 이후에 REST API가 등장하며 기존의 사용하기 어려운 복잡한 SOAP API를 대체하며 시장에서 승리하게 됩니다.

왜 REST API를?

  • 서비스를 개발하고 유지관리를 할 때, 개발자 혼자서 서비스가 문 닫을때 까지 담당하는 경우는 거의 없을것 입니다. 그러므로 정해진 규약이 필요합니다.
  • HTTP 프로토콜을 따르기 때문에 HTTP 표준 프로토콜을 따르는 많은 플랫폼에서 사용이 가능합니다.
  • 최근의 서버는 다양한 브라우저와 안드로이드폰, 아이폰과 같은 디바이스에서도 통신을 할 수 있어야 하기 때문에 REST API는 멀티 플랫폼을 지원합니다.

REST란?

REST(Representational State Transfer: 자원의 상태 전달)란, API 작동 방식에 대한 조건을 부과하는 소프트웨어 아키텍처입니다.

아키텍처라는 것은 제약조건의 집합입니다. 즉 아래의 REST의 6가지 제약조건을 따라야 REST라고 할 수 있습니다.

REST는 HTTP URI를 통하여 자원을 명시하며, HTTP 메소드(GET, POST, PUT, DELETE)를 통하여 해당 자원에 대한 CRUD Operation을 적용합니다.

REST API의 장점

확장성

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

유연성

RESTful 웹 서비스는 완전한 클라이언트-서버 분리를 지원합니다. 그러므로 서버 애플리케이션의 플랫폼 또는 기술 변경이 클라이언트 애플리케이션에 영향을 주지 않습니다.

독립성

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

REST API의 단점

Over Fetching

사용자가 필요한 것 보다 더 많은 데이터를 가져오는 경우.

Under Fetching

Over Fetching과 반대 개념으로, 사용자가 필요한 정보보다 더 적은 데이터를 가져오는 경우.

REST API 규약

REST API 6가지 제약조건

1. Client-Server

클라이언트와 서버가 서로 독립적으로 분리되어있어야 합니다.

2. Stateless

요청에 대하여 클라이언트의 상태를 서버에 저장하지 않습니다.

즉 클라이언트가 요청할 때, 햄버거 주세요 >> 콜라도 같이 주세요 가 아니라,
햄버거 주세요 >> 햄버거, 콜라주세요 이처럼 매번 새롭게 요청해야 합니다.

3. Cache

  • 클라이언트는 서버의 응답을 캐쉬(임시저장) 할 수 있어야 합니다.
  • 클라이언트가 캐쉬를 통하여 응답을 재사용 할 수 있어야 하며, 이를 통해서 서버의 부하를 낮출 수 있습니다.

4. Layered System

서버와 클라이언트 사이에 방화벽, 게이트웨이, 프록시 등 다양한 계층 형태로 구성이 가능해야 하며, 이를 확장할 수 있어야 합니다.

5. Uniform Interface

인터페이스의 일관성을 지키고, 아키텍처를 단순화시켜 작은 단위로 분리하여 클라이언트와 서버가 독립적으로 개선될 수 있어야 합니다.

인터페이스의 일관성은 아래의 4가지의 제약조건이 있습니다.

1. 자원의 식별

웹 기반의 REST에서는 리소스에 접근할 때 URI를 사용합니다.

ex) https://foo.co.kr/user/100
이 때 리소스는 user가 되며 식별자는 100 이 됩니다.

2. 메세지를 통한 리소스 조작

웹에서 가장 많이 사용하는 데이터 전달 방식은 HTML, XML, JSON, TEXT, 등이 있습니다.
이 중에서 어떠한 타입의 데이터인지 알려주기 위해서 HTTP 헤더 부분에 content-type를 통하여 데이터의 타입을 지정합니다. 또한 리소스 조작을 위하여 데이터 전체를 전달하지 않고 메세지로 전달합니다.
- ex) 서버에서 user 정보의 전화번호를 number 라고 결정하고 이 정보를 클라이언트와 주고받을 때 그대로 사용하였습니다. 그런데 그 후에 서버 리소스 변경으로 phone-number 로 바꾼다면 클라이언트는 처리하지 못하고 에러가 날 것 입니다.

이런 부분을 방지하기 위하여 별도의 메세지 형태로 데이터를 주고받고 client-sever가 독립적으로 확장 가능하게 해야 합니다.

3. 자기 서술적 메세지

  • 메세지는 스스로를 설명해야 합니다.
  • 요청하는 데이터가 어떻게 처리되어야 하는지 충분한 데이터를 포함해야 합니다.

예를 들어, 아래와 같습니다.

// 자기 서술적 메세지가 아님
HTTP/1.1 200 OK
[{
	"op": "remove",
    "path": "a/b/c"
}]
// 자기 서술적 메세지
HTTP/1.1 200 OK
Content-Type: application/json-patch+json
[{
	"op": "remove",
    "path": "a/b/c"
}]

4. 어플리케이션 상태에 대한 엔진으로써 하이퍼미디어 (HATEOAS)

  • 어플리케이션의 상태는 Hyperlink를 이용하여 전이되어야 합니다.
  • REST API를 개발할 때, 단순히 클라이언트 요청에 대한 데이터만 응답해 주는 것이 아닌, 관련된 리소스에 대한 링크 정보까지 함께 포함되어야 합니다.
  • 예를 들면 아래는 HATEOAS를 만족하는 사례입니다.
HTTP/1.1 200 OK
Content-Type: text/html

<html>
  <head></head>
  <body>
    <a href="/test">test</a>
  </body>
</html>
HTTP/1.1 200 OK
Content-Type: application/json
Link: </articles/1>; rel="previous",
	  </articles/3>; rel="next";
{
  "title": "The second article",
  "contents": "some thing blah..."
}

6. Code on Demand (Optional)

자바 애플릿, 자바스크립트, 플래시 등 특정한 기능을 서버로 부터 클라이언트가 전달받아 코드를 실행할 수 있어야 합니다.

이러한 위의 조건을 잘 갖추면 RESTful하다고 표현하며, 이를 REST API라고 부릅니다.

URI 설계

  • URI (Uniform Resource Identifier)
    • 인터넷에서 특정 자원을 나타내는 유일한 주소 값. (응답은 달라질 수 있다)
    • request : .../resource/sample/1
    • response : example.pdf
  • URL (Uniform Resource Locator)
    • 인터넷 상에서의 자원, 특정 파일이 어디에 위치하는지 식별하는 주소.
    • request : .../example.pdf
    • ※ URL은 URI의 하위개념.

URI 설계 원칙 (RFC-3986)

URI를 설계하는데는 다음과 같은 원칙이 있습니다.

  • 구분자( / )는 계층관계를 나타낸다.
  • URI 마지막 문자로 구분자( / )는 포함하지 않는다.
  • 하이픈( - ) 은 URI 가독성을 높이는데 사용한다.
  • 밑줄( _ ) 은 사용하지 않는다.
  • URI 경로에는 소문자를 사용한다.
  • 파일 확장자는 URI에 포함하지 않는다.
    • ex) .../curriculums/web-master.jsp
  • 프로그램 언어에 의존적인 확장자를 사용하지 않는다.
    • ex) .../curriculums/web-master.do
  • 구현에 의존적인 경로를 사용하지 않는다.
    • ex) .../servlet/classes/java/curriculums/web-master
  • 세션 ID 를 포함하지 않는다.
    • ex) .../curriculums/web-master?session-id=abcdef
  • 프로그래밍 언어의 method 명을 이용하지 않는다.
    • ex) .../curriculums/web-master?action=intro
  • 명사에 단수형 보다는 복수형을 사용하며 컬렉션에 대한 표현은 복수로 표현한다.
    • ex) .../classes/java/curriculums/web-master
  • 컨트롤러 이름으로는 동사나 동사구를 사용한다.
    • ex) .../curriculums/web-master/re-order
  • 경로 부분 중 변하는 부분은 유일한 값으로 대체한다.
    • .../lessons/{lesson-id}/users/{user-id}
    • .../lessons/2/users/100
  • CRUD 기능을 나타내는 것은 URI에 사용하지 않는다.
    • GET method - .../lessons/2/users/100/READ (GET이 read의 뜻)
  • URI Query Parameter 디자인
    • URI 쿼리 부분으로 컬렉션 결과에 대해서 필터링할 수 있다.
    • .../curriculums/web-master?chapter=2
  • URI Query는 컬렉션의 결과를 페이지로 구분하여 나타내는데 사용한다.
    • .../web-master?chapter=2&page=0&size=10&sort=asc
  • API에 있어서 서브도메인은 일관성있게 사용한다.
    • /api.foo.co.kr
  • 클라이언트 개발자 포탈 서브 도메인 또한 일관성있게 사용한다.
    • /dev-foo.co.kr

출처

profile
Bluewind
NO EFFORT, NO RESULTS
이전 포스트

Spring 비지니스 로직과 웹 계층

다음 포스트

JPA 란?

post-custom-banner

0개의 댓글