REST와 REST API

REST(REpresentational State Transfer)

- HTTP URI를 통해 자원(Resource)을 명시하고, HTTP Method(POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD Opertaion을 적용하는 것을 의미한다.

- 클라이언트와 서버가 데이터를 주고받는 방식에 대한 아키텍처 스타일

- REST는 기본적으로 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에 웹의 장점을 최대한 활용할 수 있는 아키텍처 스타일

- 여섯 가지 기본 원칙이 있고 이 가이드를 준수한 인터페이스를 RESTful 하다고 표현한다.

 

 

 

REST 구성 요소 : 자원, 행위, 표현

1. 자원(Resource) : URI

    > 모든 자원에 고유한 ID가 존재하고 이 자원은 server에 존재한다.

    > 자원을 구별하는 ID는 HTTP URI이다.

    > client는 URI를 이용해 자원을 지정하고 자원의 상태에 대한 조작을 server에 요청한다.

2. 행위(Verb) : HTTP Method

    > HTTP 프로토콜의 Method를 사용한다.

    > HTTP 프로토콜의 GET, POST, PUT, DELETE와 같은 메서드를 제공한다.

3. 표현(Representation of Resource)

    > Client가 자원의 상태에 대한 조작을 요청하면 Server는 이에 적절한 응답을 보낸다.

    > REST에서 하나의 자원은 JSON, XML 등 여러 형태의 Representation으로 나타내어질 수 있다.

    > JSON 혹은 XML을 통해 데이터를 주고 받는 것이 일반적이다.

 

 

 

RESTful 하다

- REST 아키텍처 스타일의 몇 가지 원칙

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

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

    > 1. 요청은 리소스를 식별해야 한다. 이를 위해 균일한 리소스 식별자 사용 

    > 2. 클라이언트는 원하는 경우 리소스를 수정하거나 삭제하기에 충분한 리소스 표현에서 가지고 있다. 서버는 리소스를 자세히 설명하는 메타데이터를 전송하여 이 조건을 충족한다.

    > 3. 클라이언트는 표현을 추가로 처리하는 방법에 대한 정보를 수신한다. 이를 위해 서버는 클라이언트가 리소스를 적절하게 사용할 수 있는 방법에 대한 메타데이터가 포함된 명확한 메시지를 전송한다

    > 4. 클라이언트는 작업을 완료하는데 필요한 다른 모든 관련 리소스에 대한 정보를 수신한다. 이를 위해 서버는 클라이언트가 더 많은 리소스를 동적으로 검색할 수 있도록 표현엔 하이퍼링크를 넣어 전송한다.

 

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

 

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

 

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

 

5) 서버-클라이언트 구조 : 자원이 있는 쪽이 server, 자원을 요청하는 쪽이 client가 된다. 

    > REST Server : API를 제공하고 비즈니스 로직 처리 및 저장을 책임진다.

    > Client : 사용자 인증이나 context(세션, 로그인 정보)등을 직접 관리하고 책임진다.

    > 서로 간 의존성이 줄어든다.

 

 

 

RESTful API 

RESTful API는 두 컴퓨터 시스템이 인터넷을 통해 정보를 안전하게 교환하기 위해 사용하는 인터페이스

 

 

 

 

RESTful API 이점

- 확장성 : REST API를 구현하는 시스템은 REST가 클라이언트-서버 상호 작용을 최적화하기 때문에 효율적으로 크기 조정할 수 있다. 무상태는 서버가 과거 클라이언트 요청 정보를 유지할 필요가 없기 때문에 서버 로드를 제거한다. 잘 관리된 캐싱은 일부 클라이언트-서버 상호 작용을 부분적으로 또는 완전히 제거한다. 이러한 모든 기능은 성능을 저하시키는 통신 병목 현상을 일으키지 않으면서 확장성을 지원한다.

- 유연성 : RESTful 웹 서비스는 완전한 클라이언트-서버 분리를 지원한다. 각 부분이 독립적으로 발전할 수 있도록 다양한 서버 구성 요소를 단순화하고 분리한다. 서버 애플리케이션의 플랫폼 또는 기술 변경은 클라이언트 애플리케이션에 영향을 주지 않는다. 애플리케이션 함수를 계층화하는 기능은 유연성을 더욱 향상한다. 예를 들어 개발자는 애플리케이션 로직을 다시 작성하지 않고도 데이터베이스 계층을 변경할 수 있다.

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

 

 

 

RESTful API 작동원리

클라이언트는 리소스가 필요할 때 API를 사용하여 서버에 접속한다.

API 개발자는 서버 애플리케이션 API 문서에서 클라이언트가 REST API를 어떻게 사용해야 하는지 설명한다.

1. 클라이언트가 서버에 요청을 전송한다. 클라이언트가 API문서에 따라 서버가 이해하는 방식으로 요청 형식을 지정한다.

2. 서버가 클라이언트를 인증하고 해당 요청을 수행할 수 있는 권한이 클라이언트에 있는지 확인한다.

3. 서버가 요청을 수신하고 내부적으로 처리한다.

4. 서버가 클라이언트 응답을 반환한다. 응답에는 요청이 성공했는지 여부를 클라이언트에 알려주는 정보가 포함된다. 응답에는 클라이언트가 요청한 모든 정보도 포함된다.

 

 

API 

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

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

 

 

 

RESTful API Naming

- URI(Uniform Resource Identifier)

    - Uniform : 리소스를 식별하는 통인 된 방식

    - Resource : 자원, URI로 식별할 수 있는 모든 것(제한 없음)

    - Identifier : 다른 항목과 구분하는데 필요한 정보

- URI는 Resource만 식별

- 최근에는 Resource 대신 Representation이라는 표현 사용하기 시작

 

 

1. 리소스를 표현하기 위해 명사 사용

RESTful URI가 가리키는 resource는 수행되는 행위가 아니라 객체이다.

resource를 네 가지 범주로 나누고 항상 리소스가 어디에 해당하는지 확인 후 그 범주에 맞는 네이밍 컨벤션을 일관되게 사할 것.

 

1-1. 문서 (Document)

    - 단일 개념(파일 하나, 객체 인스턴스, 데이터베이스 row)

    - 단수 사용(/device-management, /user-management)

    - http://api.example.com/user-management/users/{id}

 

1-2. 컬렉션(Collection)

    - 서버가 관리하는 리소스 디렉터리

    - 서버가 리소스의 URI를 생성하고 관리

    - 복수를 사용하라

    - POST 기반 등록

    - 복수 사용(/users)

    - http://api.example.com/user-management/users 

 

1-3. 스토어(Store)

    - 클라이언트가 관리하는 자원 저장소

    - 클라이언트가 리소스의 URI를 알고 관리

    - PUT 기반 등록

    - 복수 사용(/files)

    - http://api.example.com/files

    - http://api.example.com/files/new_files.txt

 

1-4. 컨트롤 URI 혹은 컨트롤러(Controller)

    - 문서, 컬렉션, 스토어로 해결하기 어려운 추가 프로세스 실행

    - 동사를 직접 사용

    - http://api.example.com/cart-management/users/{id}/playlist/play 

 

2. 일관성이 핵심이다.

일관된 resource naming conventions와 URI 형식을 사용하면 모호함이 최소화되고 가독성과 지속성이 극대화된다. 일관성을 위해 다음과 같은 디자인 힌트를 구현할 수 있다.

    - 계층 관계 표현을 위해 / 사용

    - 마지막 문자로 / 사용 금지

    - 가독성을 위해 -(하이픈) 사용

    - _(언더스코어) 사용 금지, 일반 브라우저나 화면에서는 언더스코어는 가려질 수 있음

    - 소문자 사용

    - 파일 확장자 사용 금지

 

3. CRUD 함수명 사용 금지

URI는 어떤 동작이 수행되는지 가리키는게 아니라 리소스를 가르키는 것

    - 리소스에 대한 작업은 HTTP Method를 이용

    - HTTP GET http://api.example.com/device-management/managed-devices/{id}  //Get device for given Id
    - HTTP PUT http://api.example.com/device-management/managed-devices/{id}  //Update device for given Id
    - HTTP DELETE http://api.example.com/device-management/managed-devices/{id}  //Delete device for given Id

 

4. 필터를 위해 쿼리 파라미터 사용

Resource에 대한 정렬, 필터링, 페이징은 신규 API를 생성하지 않고 쿼리 파라미터를 활용한다.

    - http://api.example.com/device-management/managed-devices?region=USA 

 

 

 

HTTP 응답 상태 코드 

잘 설계된 REST API는 URI만 잘 설계된 것이 아닌 그 리소스에 대한 응답을 잘 내어주는 것까지 포함되어야 한다. 정확한 응답의 상태코드만으로도 많은 정보를 전달할 수 있기 때문에 상태코드 값을 명확히 돌려주는 것은 중요하다.

 

 

 

 

---

(참고)

RESTful API를 위한 6가지 원칙과 네이밍 (tistory.com)

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

https://meetup.toast.com/posts/92

https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html