REST, REST API, RESTful 개념 정리

REST란

REpresentational State Transfer의 약자로, 자원을 이름(자원의 표현)으로 구분해 해당 자원의 상태(정보)를 주고 받는 모든 것을 의미합니다.
uri와 method만 보았을 때 이 API가 어떤 동작을 하는 API인지 누가봐도 알 수있도록 설계하는 것이 핵심이다.

 

REST의 개념

어떤 자원에 대해 CRUD 연산을 수행하기 위해 URI(Resource)로 GET, POST 등의 방식(Method)을 사용하여 요청을 보내며, 요청을 위한 자원은 특정한 형태(Representation of Resource)로 표현된다.

URI 와 URL의 차이점?
URL은 Uniform Resource Locator로 인터넷 상 자원의 위치를 의미합니다.
반면 URI는 Uniform Resource Identifier로 인터넷 상의 자원을 식별하기 위한 문자열의 구성으로,
URI는 URL을 포함하게 됩니다. URI가 URL보다 포괄적인 범위라고 할 수 있습니다.

 

REST의 구성 요소

1. 자원(Resource) - URI
   • 모든 자원에는 고유한 ID가 존재하고, 이 자원은 Server에 존재한다.
   • 자원을 구별하는 ID는 '/exgroups/:exgroup_id'와 같은 HTTP URI이다.
   • Client는 URI를 이용해 자원을 지정하고 해당 자원의 상태(정보)에 대한 조작을 Server에 요청한다.
2. 행위(Verb) - Method
   
   • HTTP 프로토콜의 method를 사용한다.
   • HTTP 프로토콜은 GET, POST, PUT, PATCH, DELETE의 Method를 제공한다.
     

     GET	Read : 정보 요청, URI가 가진 정보를 검색하기 위해 서버에 요청한다.
     POST	Create : 정보 입력, 클라이언트에서 서버로 전달하려는 정보를 보낸다.
     PUT	Update : 정보 업데이트, 주로 내용을 갱신하기 위해 사용한다. (데이터 전체를 바꿀 때)
     PATCH	Update : 정보 업데이트 주로 내용을 갱신하기 위해 사용한다. (데이터 일부만 바꿀 때)
     DELETE	Delete : 정보 삭제 (안전성 문제로 대부분 서버에서 비활성화한다.)

3. 표현(Representation of Resource)
   • Client와 Server가 데이터를 주고받는 형태로 JSON, XML, TEXT, RSS등이 있다.
   • JSON, XML을 통해 데이터를 주고 받는 것이 일반적이다.

 

REST의 특징

1. Server-Client (서버-클라이언트 구조)
   • 자원이 있는 쪽이 Server, 자원을 요청하는 쪽이 Client가 된다.
     • REST Server는 API를 제공하고 비즈니스 로직 처리 및 저장을 책임진다.
     • Client는 사용자 인증이나 context(세션, 로그인 정보) 등을 직접 관리하고 책임진다.
     • 역할을 확실히 구분시킴으로써 서로 간의 의존성을 줄인다.
2. Stateless (무상태)
   • HTTP 프로토콜은 Stateless Protocol이므로 REST 역시 무상태성을 갖는다.
   • Client의 context를 Server에 저장하지 않는다. (즉, 세션과 쿠키와 같은 context 정보를 신경쓰지 않아도 되므로 구현이 단순해진다.)
   • Server는 각각의 요청을 완전히 별개의 것으로 인식하고 처리한다.
     • 각 API 서버는 Client의 요청만을 단순 처리한다.
     • 이전 요청이 다음 요청의 처리에 연관 되어서는 안된다. (DB에 의해 바뀌는 것은 허용)
     • Server의 처리 방식에 일관성을 부여하기 때문에 서비스의 자유도가 높아진다.
3. Cacheable (캐시 처리 기능)
   • 웹 표준 HTTP 프로토콜을 그대로 사용하므로 웹에서 사용하는 기존의 인프라를 그대로 활용할 수 있다.
     • HTTP가 가진 가장 강력한 특징 중 하나인 캐싱 기능을 적용할 수 있다.
     • HTTP 프로토콜 표준에서 사용하는 Last-Modified Tag 또는 E-Tag를 이용해 캐싱을 구현한다.
   • 대량의 요청을 효율적으로 처리할 수 있다.
4. Layered System (계층 구조)
   • Client는 REST API Server만 호출한다.
   • REST Server는 다중 계층으로 구성될 수 있다.
     • 보안, 로드 밸런싱, 암호화 등을 위한 계층을 추가하여 구조를 변경할 수 있다.
     • Proxy, Gateway와 같은 네트워크 기반의 중간매체를 사용할 수 있다.
     • Client는 Server와 직접 통신하는지, 중간 서버와 통신하는지는 알 수 없다.
5. Uniform Interface (인터페이스 일관성)
   • URI로 지정한 Resource에 대한 요청을 통일되고, 한정적으로 수행하는 아키텍처 스타일을 의미한다.
   • HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하며, Loosely Coupling(느슨한 결함) 형태를 갖는다.
     • 특정 언어나 기술에 종속되지 않는다.
6. Self-Descriptiveness (자체표현)
   • 요청 메시지만 보고도 쉽게 이해할 수 있는 자체 표현 구조로 되어있다.

 

---

 

REST API란

• REST의 특징을 기반으로 서비스 API를 구현한 것
• 최근 OpenAPI, 마이크로 서비스 등을 제공하는 기업 대부분은 REST API를 제공한다.

 

REST API의 특징

• REST API의 가장 큰 특징은 각 요청이 어떤 동작이나 정보를 위한 것인지를 그 요청의 모습 자체로 추론이 가능하다.

 

REST API 디자인 가이드

1. URI는 정보의 자원을 표현해야 한다.
2. 자원에 대한 행위는 HTTP Method(GET, POST, PUT, PATCH, DELETE)로 표현한다. (행위(Method)는 URI에 포함하지 않는다.)

 

REST API의 설계 규칙

1. URI는 명사를 사용한다. (리소스명은 동사가 아닌 명사를 사용해야 한다.)
   • 아래와 같은 동사를 사용하면 안된다.
     • /getAllUsers
     • /createNewUser
     • /updateUser
2. 슬래시( / )로 계층 관계를 표현한다.
3. URI 마지막 문자로 슬래시( / )를 포함하지 않는다.
4. 밑줄( _ )을 사용하지 않고, 하이픈( - )을 사용한다.
5. URI는 소문자로만 구성한다.
6. HTTP 응답 상태 코드 사용한다.
   1. 클라이언트는 해당 요청에 대한 실패, 처리완료 또는 잘못된 요청 등에 대한 피드백을 받아야 한다.
7. 파일확장자는 URI에 포함하지 않는다.
   1. ex) http://tistory.com/restapi/2/photo.jpg (X)

※ 응답상태코드

1xx : 전송 프로토콜 수준의 정보 교환
2xx : 클라어인트 요청이 성공적으로 수행됨
3xx : 클라이언트는 요청을 완료하기 위해 추가적인 행동을 취해야 함
4xx : 클라이언트의 잘못된 요청
5xx : 서버쪽 오류로 인한 상태코드

 

---

 

RESTful API란

REST의 설계 규칙을 잘 지켜서 설계된 RESTful한 API를 RESTful API라고 한다.

 

RESTful 특징

• HTTP와 URI 기반으로 자원에 접근할 수 있도록 제공하는 애플리케이션 개발 인터페이스이다. 기본적으로 개발자는 HTTP 메소드와 URI 만으로 인터넷에 자료를 CRUD 할 수 있다.
• 'REST API'를 제공하는 웹 서비스를 'RESTful' 하다고 할 수 있다.
• RESTful은 REST를 REST 답게 쓰기 위한 방법으로, 누군가가 공식적으로 발표한 것은 아니다.
• RESTful은 일반적으로 REST라는 아키텍처를 구현하는 웹 서비스를 나타내기 위해 사용되는 용어이다.
• RESTful은 REST를 REST답게 쓰기 위한 방법으로, 누군가가 공식적으로 발표한 것이 아니다. 즉, REST 원리를 따르는 시스템은 RESTful이란 용어로 지칭된다.

 

RESTful API 개발 원칙

1. 자원을 식별할 수 있어야 한다.
   • URL (Uniform Resource Locator) 만으로 내가 어떤 자원을 제어하려고 하는지 알 수 있어야 한다. 자원을 제어하기 위해서, 자원의 위치는 물론 자원의 종류까지 알 수 있어야 한다는 의미이다.
   • Server가 제공하는 정보는 JSON 이나 XML 형태로 HTTP body에 포함되어 전송 시킨다.
2. 행위는 명시적이어야 한다.
   • REST는 아키텍쳐 혹은 방법론과 비슷하다. 따라서 이런 방식을 사용해야 한다고 강제적이지 않다. 기존의 웹 서비스 처럼, GET을 이용해서 UPDATE와 DELETE를 해도 된다.
   • 다만 REST 아키텍쳐에는 부합하지 않으므로 REST를 따른다고 할 수는 없다.
3. 자기 서술적이어야 한다.
   • 데이터에 대한 메타정보만 가지고도 어떤 종류의 데이터인지, 데이터를 위해서 어떤 어플리케이션을 실행 해야 하는지를 알 수 있어야 한다.
   • 데이터 처리를 위한 정보를 얻기 위해서, 데이터 원본을 읽어야 한다면 자기 서술적이지 못하다
4. HATEOS (Hypermedia as the Engine of Application State)
   • 클라이언트 요청에 대해 응답을 할 때, 추가적인 정보를 제공하는 링크를 포함할 수 있어야 한다.
   • REST는 독립적으로 컴포넌트들을 손쉽게 연결하기 위한 목적으로도 사용된다. 따라서 서로 다른 컴포넌트들을 유연하게 연결하기 위해선, 느슨한 연결을 만들어줄 것이 필요하다.
   • 이때 사용되는 것이 바로 링크이다. 서버는 클라이언트 응용 애플리케이션에 하이퍼 링크를 제공한다.
   • 클라이언트는 이 하이퍼 링크를 통해서 전체 네트워크와 연결되며 HATEOAS는 서버가 독립적으로 진화할 수 있도록 서버와 서버, 서버와 클라이언트를 분리 할 수 있게 한다.

 

RESTful API 제약조건

• URI는 자원을 표현해야함
• 클라이언트 또는 서버에서 관리하는 리소스는 복수로 표현하는게 좋으며, 인스턴스는 단수를 사용
  (ex. /users/:userIdx, /users/photo)
• URI에는 최대한 명사만 사용하는것이 좋으며, 동사의 역할은 method가 할 수있도록 함
• 언더바 사용은 안되며, 필요한 경우 하이픈 사용(-)
• 마지막 슬래시(/)는 붙이지 않음
• 대문자보다 소문자 사용
• 파일 확장자는 포함하지 않음. (ex. /users/photo.png)

 

RESTful한 API 설계 예시

• POST /users -> 사용자 등록(=회원가입)
• GET /users -> 모든 사용자 조회
• GET /users/:userIdx -> userIdx에 해당하는 사용자 조회
• POST /boards -> 게시글 등록
• GET /boards -> 모든 게시글 조회
• GET /boards/:boardIdx -> boardIdx에 해당하는 게시글 조회
• PATCH 또는 PUT /boards/:boardIdx -> boardIdx에 해당하는 게시글 수정
• DELETE /boards/:boardIdx -> boardIdx에 해당하는 게시글 삭제
• GET /boards/:boardIdx/comments -> boardIdx에 해당하는 게시글의 댓글 조회
• GET /users/:userIdx/image -> userIdx에 해당하는 사용자의 이미지 조회

 

Restful API 인증 방식

• API 키 방식 : 유저별로 String key 사용
• API Token : API 호출에 사용할 기간이 유효한 토큰을 발급. 연쇄 개인정보 탈취를 방지
• HTTP Basic Auth : 아이디 비밀번호를 요구하는 로그인 창이 표시되고 HTTP Header에 Base64 인코딩을 통해 인증데이터를 전송한다. 네트워크 상에서 패킷탈취 및 디코딩 가능성이 있으므로 보안 프로토콜을 사용해야 한다.
• Digest Access Authentication : 클라이언트가 인증을 요청할 때 클라이언트가 서버로부터 난수값을 받고, 그 난수값을 이용해 데이터를 해싱하는 형태이다 중간자 공격에서도 비밀번호 등의 추출을 어려워서 Basic Auth보다 향상된 보안을 제공한다.
• 제 3자 인증(OAuth 2.0)
• JWT (Json Web Token) : 권한 인가내용을 같이 삽입. 성능상의 이점이 생긴다

 

---

※참고

 

GET 방식과 POST 방식의 차이점

• Get은 주로 웹 브라우저가 웹 서버에 데이터를 요청할 때 사용
• Post는 웹 브라우저가 웹 서버에 데이터를 전달하기 위해 사용.
• Get을 사용하면 웹 브라우저에서 웹 서버로 전달되는 데이터가 인코딩되어 URL에 붙는다.
• Post방식은 전달되는 데이터가 URL에 표시되지 않는다.
• Get방식은 전달되는 데이터가 255개의 문자를 초과하면 문제가 발생할 수 있다.
• 웹서버에 많은 데이터를 전달하기 위해서는 Post 방식을 사용하는 것이 바람직하다.

 

PUT과 PATCH의 차이점

PUT은 자원의 전체 교체 및 수정이 필요할 때 사용하고, PATCH는 자원의 일부만 수정되거나 교체될 때 사용된다.
따라서 DB의 특정 칼럼만 수정하고자 한다면 PATCH를 사용하고 그게 아니라 전부다 수정되야하는 사항이라면 PUT을 사용하면 된다.