REST란?

• REST(REpresentational State Transfer)란 웹에 존재하는 모든 자원(resorce, ex. 이미지, 동영상, 데이터)에 고유한 URI를 부여하여 자원에 대한 주소를 지정하는 방법론, 또는 규칙

• 월드 와이드 웹(www)과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 개발 아키텍처의 한 형식

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

• 네트워크 상에서 Client와 Server 사이의 통신 방식 중 하나

RESTful API의 특징

• 사내 시스템들도 REST 기반으로 시스템을 분산해 확장성과 재사용성을 높여 유지보수 및 운용을 편리하게 할 수 있다.

• REST는 HTTP 표준을 기반으로 구현하므로, HTTP를 지원하는 프로그램 언어로 클라이언트, 서버를 구현 가능

• REST API를 제작하면 델파이 클라이언트 뿐 아니라, 자바, C#, 웹 등을 이용해 클라이언트를 제작 가능

RESTful API 설계 규칙

리소스 원형

도큐먼트 : 객체 인스턴스나 데이터베이스 레코드와 유사한 개념
컬렉션 : 서버에서 관리하는 디렉터리라는 리소스
스토어 : 클라이언트에서 관리하는 리소스 저장소

1. URI는 정보의 자원을 명확하게 표현해야 한다.

   • resource는 동사보다는 명사를, 대문자보다는 소문자를 사용
   • resource의 도큐먼트 이름으로는 단수 명사를 사용
   • resource의 컬렉션 이름으로는 복수 명사를 사용
   • resource의 스토어 이름으로는 복수 명사를 사용

2. 자원에 대한 행위는 HTTP Method(GET, PUT, POST, DELETE 등)로 표현한다.

   • URI에 HTTP Method가 들어가면 안된다.
   • URI에 행위에 대한 동사 표현이 들어가면 안된다.
     (CRUD 기능을 나타내는 것은 URI에 사용하지 않는다.)
   • 경로 부분 중 변하는 부분은 유일한 값으로 지정한다.
     예시) :id는 하나의 특정 resource를 나타내는 고유값

3. resource 사이에 연관 관계가 있는 경우

   • / 리소스명 / 리소스ID / 관계가 있는 다른 리소스명
     예시) /users/{user_id}/profile

4. 파일의 포맷을 나타내기 위한 파일 확장자를 URI에 포함시키지 않는다.

5. URI의 슬래시(/)는 resource의 계층관계를 나타내는데 사용한다.

6. URI 마지막 문자로 슬래시(/)를 포함하지 않는다.
   REST API는 분명한 URI를 만들어 통신을 해야 하기 때문에 혼동을 주지 않도록 URI 경로의 마지막에는 슬래시(/)를 사용하지 않는다.

7. 불가피하게 URI가 길어지는 경우 하이픈(-)을 사용하여 가독성을 높이며 밑줄(_)은 URI에 사용하지 않는다.
   밑줄은 보기 어렵거나 밑줄 때문에 문자가 가려지기도 하므로 가독성을 위해 밑줄은 사용하지 않는다.

8. URI 경로에는 소문자가 적합하다.

   • URI 경로에 대문자 사용은 피하도록 한다.
   • URI 문법 형식은 URI스키마와 호스트를 제외하고는 대소문자를 구별하도록 규정하기 때문

RESTful API 장단점

장점

1. Easy to use(쉬운 사용)
REST API 메시지를 읽는 것만으로도 의도하는 바를 명확하게 파악할 수 있습니다.

2. 별도의 인프라 불필요
HTTP 인프라를 그대로 사용하므로 REST API 사용을 위한 별도의 인프라를 구축할 필요가 없습니다.

3. 서버와 클라이언트의 역할을 명확하게 분리
Stateless한 특징 때문에 Execution Context가 독립적으로 진행됨으로써 이전에 서버(호스트)에서 진행된 내용들에 대해 클라이언트가 알 필요가 없으며, 이제까지 진행된 히스토리에 대해서도 알 필요가 없습니다. 즉, 해당 URI와 원하는 메서드 자체만 독립적으로 이해하면 됩니다.

각자의 역할이 명확하게 분리되어있다는 장점은 단순히 업무량 감소를 넘어 플랫폼의 독립성 확장이라는 효과를 가져오며, HTTP 프로토콜 서비스라는 기본적인 요구만 충족된다면 다양한 플랫폼에서 원하는 서비스를 쉽고 빠르게 개발하고 배포할 수 있습니다.

4. Detail expression for specific data type
REST API는 헤더 부분에 URI 처리 메소드를 명시함으로써, 필요한 실제 데이터를 payload(바디)에 표현할 수 있도록 구성할 수 있는 기능을 제공합니다. 이는 특정 메서드의 세부적인 표현 문구를 JSON, XML 등 다양한 언어를 이용하여 작성할 수 있다는 장점 뿐만 아니라, 간결한 헤더 표현을 통한 가독성 향상이라는 두마리 토끼를 잡는 효과를 가져다 줍니다.

단점

1. Restriction of HTTP Method
REST API는 HTTP 메소드를 사용하여 URI를 표현합니다. 이러한 표현 방법은 다양한 인프라에서도 편리하게 사용할 수 있다는 장점을 주지만, 또 한편으로는 메소드 형태가 제한적 이라는 문제점을 가져오기도 합니다.

내부 Context를 이용할 수 있습니다. 하지만 이 방법이 모든 부분에서 해결책을 제공하지는 못합니다.

2. Absence of Standard (표준의 부재)
REST API의 가장 큰 단점이라고 할 수 있는데, 바로 표준이 존재하지 않습니다. 관리의 어려움과 좋은(공식화 된) API 디자인 가이드가 존재하지 않아 결국 많은 사람들이 하나씩 쌓아올리는 약속들과 같다고 할 수 있습니다.

이 부분에 대해 어떤 사람들은 '확장성과 발전 가능성'을 이야기하지만 표준이 존재하지 않다보니 많이 사용되는 패턴이어도 비효율적이거나 비생산적인 패턴으로 작성되는 경우들이 많습니다.

참고 링크

• https://sabarada.tistory.com/28?category=800100
• https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html