[Network] REST, REST API, RESTful

 

1. REST(Respresentational State Transfer)

        REST는 자원을 이름으로 구분하여 해당 자원의 상태(정보)를 주고 받는 모든 것을 의미합니다. 쉽게 얘기하면 HTTP를 잘 사용하기 위한 아키텍처 스타일 입니다.

 

CRUD Operation란?

CRUD는 데이터 처리 기능인 Create(생성), Read(읽기), Update(갱신), Delete(삭제)를 묶어서 일컫는 말이다.

REST에서의 CRUD는 POST(데이터 생성), GET(데이터 조회), PUT, PATCH(데이터 수정), DELETE(데이터 삭제) 이다.

 

 

 

REST 구성 요소

1. 자원(Resource) - HTTP URI

• Uniform Resource Identifier의 약자인 URI 뜻은 우리말로 ‘통합 자원 식별자’입니다.
• URI는 식별자, URL은 식별자 + 위치를 포함합니다.
• 예를 들어 run-ran-run-ant.tistory.com 은 리소스의 이름만 나타내기 때문에 URI입니다. https://run-ran-run-ant.tistory.com은 프로토콜(https)이 포함이 되어있으므로 URL 입니다.  

 

 

2. 자원에 대한 행위(Verb) - HTTP Method

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 (무상태)

• 무상태성 - 서로의 상태를 기억하지 않는다.
• 클라이언트에서 서버로 요청에는 그 요청을 이해하는데 필요한 모든 정보가 포함되어 있어야 합니다.
• 클라이언트, 서버 모두 통신하는 상대의 상태정보를 따로 저장하고 관리하지 않습니다.
• 요청과 응답이 들어올 때 마다, 상대가 누구인지 파악할 수 있어야합니다.
• 세션 정보나 쿠키 정보를 별도로 저장하지 않기 때문에, API 서버는 단순히 들어오는 요청만 처리하면 됩니다.
• 서버에서 불필요한 정보를 관리하지 않음으로써 구현이 단순해집니다.

 

3. Cacheable (캐시 처리 기능)

• 요청에 대한 응답 내의 데이터에 캐시 가능여부가 명시되어 있어야함을 의미합니다.
• HTTP 프로토콜 표준에서 사용하는 Last-Modified Tag 또는 E-Tag를 이용해 캐싱을 구현해 대량의 요청을 효율적으로 처리할 수 있습니다.

Last-Modified Tag, E-Tag 참고)

https://blog.naver.com/PostView.naver?blogId=youngchanmm&logNo=222189300544&parentCategoryNo=&categoryNo=44&viewDate=&isShowPopularPosts=true&from=search 

 

https://adunhansa.tistory.com/256

 

 

 

4. Uniform Interface

• 전체적인 시스템 아키텍처를 언어 및 플랫폼에 상관없이 어디서든 사용할 수 있도록 약속된 인터페이스를 제공해야합니다.
• 이 인터페이스를 일반화 시킴으로써, 클라이언트-서버 간 결합도를 낮출 수 있습니다.

 

 

1) URI를 통해 자원을 식별할 수 있어야 합니다.

    회원 목록 조회/ 회원 조회의 요구사항에 대한 자원은 회원뿐 입니다. 회원을 조회하고, 등록하고, 수정하고, 삭제하는 명령어가 자원을 의미하지 않고, 자원을 식별할 수 있는 식별자 값이 아닙니다. 

• 잘못된 예시
  https://company.com/read-member-list   - 회원 목록 조회
  https://company.com/read-members-id   - 회원 조회
• REST를 지킨 예시
  https://company.com/members        - 회원 목록 조회
  https://company.com/members/{id}  - 회원 조회

 

     따라서, URI에 제어하고자 하는 자원에 대해 명시하고, 그 객체를 식별할 수 있는 식별자{id}를 URI를 통해서 식별 할 수 있도록 해줘야 합니다.

 

출처-https://thalals.tistory.com/335

 

 

 

 

2) 표현을 통한 자원에 대한 조작(Manipulation of resources through representations)

    표현을 통한 자원에 대한 조작이란, HTTP 메소드(표현)을 통해 HTTP 메세지에 해당 리소스에 대해 어떤 조작을 하는지 명시하라는 것입니다.  

 

 

 

 

 

3) 자기 서술적 메세지(Self-descriptive messages)

    메세지는 스스로를 설명할 수 있어야 합니다. 메세지를 읽는 모든 주체들이, 메세지의 모든 요소는 메세지만 보고 그 의미를 파악할 수 있어야 합니다. 

 

 

    ① 미디어 타입 정의하는 방법

 

    HTTP/1.1 200 OK

    [{"op":"remove", "path":"/manage/newpost"}]

 

 

    위 메세지는 클라이언트(컴퓨터)가 읽을 때 메세지의 타입을 인식하지 못합니다.

 

 

    HTTP/1.1 200 OK

    Content-Type:application/json-patch+json

    [{"op":"remove", "path":"/manage/newpost"}]

 

 

 

    Content-Type에 미디어 타입이 명시되어 있어야지 클라이언트(컴퓨터)가 알 수 있습니다. 메세지를 만들기 전에 Content-Type에 기술한 미디어 타입 즉, json patch의 명세를 작성하고, 그 문서를 보고 op, path를 알 수 있습니다. (매번 새로운 Media type을 등록해야한다.)

 

 

 

 

 

    ② Link Profile을 사용하는 방법

 

출처-https://jindream6128.tistory.com/13

    Link 헤더에 작성된 api 명세서 링크를 첨부하고, rel="profile"을 명시하는 방법입니다. 이 메세지를 보는 사람은 명세를 찾아 갈 수 있으므로, 온전히 해석이 가능합니다.

 

 

 

 

 

 

 

4) HATEOAS - Hypermedia as the engine of application state

    하이퍼 미디어를 통한 앱 상태 변경 인터페이스를 제공해야 합니다. HATEOAS 제약조건을 쉽게 말하면, 페이지를 이동할 때, 해당 페이지에 있던 링크(하이퍼링크)를 따라서 이동해야 한다는 제약조건입니다. (거의 모든  REST API에서 지키지 못하는 부분입니다.) 

 

 

예)  HTML은 HATEOAS를 만족합니다. a태그를 통해서 Hyperlink를 사용한 상태 전이가 가능하기 때문입니다. 

다음의 하이퍼링크

 

 

 

 

 

 

5. Layered System (계층화 시스템)

• 클라이언트는 서버에 직접 연결되었는지, 중간 서버를 통해 연결되었는지 알 수 없어야함을 의미합니다.

 

 

---

 

 

 

2. REST API

      REST API는 HTTP를 잘 사용하기 위해, REST 아키텍쳐 스타일을 모두 준수해서 API 서비스를 구현한 것 입니다. 

 

REST  API의 설계 규칙

1) URI는 형용사, 동사보다는 명사를, 대문자보다는 소문자를 사용하여야 한다.

(단, 컨트롤 자원을 의미하는 경우 예외적으로 동사를 사용한다.)

- 예시

https://run-ran-run-ant.tistory.com/manage/Newpost(x)

https://run-ran-run-ant.tistory.com/manage/newpost(o)

 

https://run-ran-run-ant.tistory.com/manage/writeNewpost(x)

 

 

2) 마지막에 슬래시(/)를 포함하지 않는다.

- 예시

https://run-ran-run-ant.tistory.com/manage/newpost/(x)

https://run-ran-run-ant.tistory.com/manage/newpost(o)

 

 

3) 언더바( _ ) 대신 하이폰(-)을 사용한다.

- 예시

https://run-ran-run-ant.tistory.com/manage/new_post(x)

https://run-ran-run-ant.tistory.com/manage/new-post(o)

 

 

4) 파일 확장자는 URI에 포함하지 않는다.

- 예시

https://run-ran-run-ant.tistory.com/manage/newpost.png(x)

https://run-ran-run-ant.tistory.com/manage/newpost(o)

 

 

5) 행위를 포함하지 않는다. (행위는 URI 대신 Method를 사용하여 전달한다.)

- 예시

https://run-ran-run-ant.tistory.com/post/newpost(x)

https://run-ran-run-ant.tistory.com/newpost(o)

 

 

6) URI에 작성되는 영어를 복수형으로 작성한다. (문법적으로는 맞지 않지만, 실무에서 사용)

- 예시

https://run-ran-run-ant.tistory.com/courses(O)

 

 

 

 

 

 

3. RESTful API

• RESTful은 REST의 설계 규칙을 잘 지켜서 설계된 API를 RESTful한 API라고 합니다. 즉, REST 원리를 잘 따르는 시스템을 RESTfUL이란 용어로 지칭됩니다.
• RESTful API는 주소만 봐도 어떤 것을 요청하는지 파악이 가능할 정도로 이해하기 쉽고, 사용하기 쉬운 REST API를 만드는 것을 목적으로 합니다.

 

 

 

 

 

 

 

 

 

 

질문&답변

1. REST API, RESTful 차이점에 대해 설명해주세요.

• REST한 방식으로 클라이언트와 서버간 상호 데이터 교환을 하는 API이며, 서로간에 stateless한 특징을 가진 API입니다.
• 추가로 Hypermedia (링크)를 통해서 애플리케이션의 상태 전이가 가능해야 하고 Hypermedia (링크)에 자기 자신에 대한 정보가 담겨야 한다. 

 

 

2. REST API 장점은 무엇인가요?

•  URL만 보고 어떤 자원에 접근할 것인지, 메소드를 보고 어떤 행위를 할지 알 수 있기 때문에 개발할 때 용이합니다.
• 1개의 URI로 4개의 행위(CRUD)를 명시할 수 있기 때문에 자원을 아낄 수 있습니다.
• stateless(무상태성)한 상태를 유지할 수 있습니다. REST API의 가장 큰 특징으로, 클라이언트가 서버에 종속적이지 않아도 되기때문에, scale out한 상황에서도 용이하고, 다양한 브라우저와 모바일에서 통신할 수 있도록 합니다.
  (scale-up : 기존 서버를 보다 높은 사양으로 업그레이드, scale-out : 장비를 추가해 서버 확장)

 

 

 

 

Referance

https://dev-coco.tistory.com/97

https://thalals.tistory.com/284

https://thalals.tistory.com/335

[Restful api 란] - 진짜 Rest API 란 무엇이고 어떻게 써야하는 걸까?