Restful에 대한 이해하기(Restful 특징) - 4

이 글은 제가 C++ Restful 인 casablanca를 개발하는데 앞서 일반적인 Restful의 정의를 알아보고자 작성하는 글입니다.

조사 기간은 7일걸렸습니다.

 

 

목차는 다음과 같이 진행됩니다.

 

1. 웹의 역사(Restful의 탄생 배경을 알아보기 위해선 시작점을 이해해야 했습니다.)

보러가기 : https://hwan-shell.tistory.com/139

2. xml과 json, soap의 통신 방식과 단점.

보러가기 : https://hwan-shell.tistory.com/140

3. Restful 과 soap의 차이점.

보러가기 : hwan-shell.tistory.com/141?category=826872

4. Restful의 특징

 

 

 

※REST는 무언가 대단한것이 아니며 꼭 이러한 규칙을 따를 필요는 없습니다.

단지 REST가 지니는 장점이 단점보다 많고, 많은 사람들이 REST아키텍처를 사용하고 있기 때문에 사용하는 것입니다.

REST는 프로그래머가 함수를 만들듯 REST아키텍처의 규칙에 맞게 설계하는 것입니다.

 

 

 

Rest는 기본적으로 GET, POST, UPDATE, DELETE의 키워드를 가지고 해당 키워드의 의미에 맞게 구현합니다.

 

GET - 서버로 부터 정보를 얻어올 때 (Read)

POST - 서버(DB)에 무언가를 생성하고자 할 때 (Create)

PUT - 서버(DB)를 수정할 때 (Update)

DELETE - 서버(DB)의 내용을 지울 때 (Delete)

 

 

여기서 서버에 직접적으로 접근해 수정하는 것이 아닌 서버에 등록된 리소스를 가르키는 말입니다.

예를 들자면 인터넷에서 글쓰기를 할 때를 생각하시면 됩니다.

 

 

클라이언트 입장에선 위 4가지의 동작에 맞게 프로그램을 설계하면 됩니다.

(물론 POST로 GET의 역할을 하게끔 만들 수 있고 반대로도 가능합니다. 하지만 그렇게 되버리면

Rest 아키텍처의 조건에 어긋나게 되므로 잘 만들어야 합니다.)

 

 

 

Rest 아키텍처에 적용되는 6가지 조건은 다음과 같습니다.

 

1. Uniform interface

일관적인 인터페이스로 구성되어야 합니다. 즉, 어떤 플랫폼이건(Android, rinux, IOS 등...) URI를 통한 접근이 가능해야 합니다.

 

2. Stateless

서버는 클라이언트의 상태를 알 필요가 없다. 즉, 세션유지를 하지 않습니다. 

Rest는 HTTP통신으로 클라이언트의 요청이 있을 때 해당 자료만 건내주면 되기 때문입니다.

따라서 클라이언트가 몇번 접속했고, 클라이언트는 최근 어디까지 데이터 요청을 했던 서버는 알 필요가 없습니다.

 

3. Cacheable

Rest는 기본적인 HTTP방식을 사용합니다. 즉 기본적인 웹 통신에서의 케시를 사용할 수 있습니다.

대표적인 예로 인터넷에 접속하면 이미지나 문서들은 클라이언트 캐시에 저장되고 동일한 요청이 일어나면

서버에서 다시 받아오는것이 아닌 캐시에서 꺼내다 사용합니다. 때문에 서버의 부하를 줄이고 속도를 증가시키는

효과를 가져올 수 있는데 이 특징은 HTTP통신에서 가능합니다. 

Rest는 HTTP통신을 하므로 캐시 사용 또한 가능합니다.

 

4. Client - Server 구조

클라이언트와 서버의 역할을 확실하게 나눠야 합니다. 즉, 서버는 API만을 제공하며, 클라이언트는 로그인 정보, 세선같은 것들을

잘 관리해야 합니다.

 

5. 계층화(Layered System)

클라이언트는 보통 대상 서버에 직접 연결되었는지, 또는 중간 서버를 통해 연결되었는지를 알 수 없습니다.

클라이언트는 그냥 서버로부터 데이터만 받으면 되기 때문입니다. 따라서 서버로 가는 경로마다 로드벨런스나 공유 캐시 등을 넣어

시스템 규모 확장에 유용합니다.

 

6. Code Demand Constraint

REST는 applets 또는 script 형태로 코드를 다운로드하고 실행하여 클라이언트 기능을 확장 할 수 있습니다. 이는 사전 구현에 필요한 기능의 수를 줄임으로써 클라이언트를 단순화합니다. 배포 후 기능을 다운로드하면 시스템 확장 성이 향상됩니다. 그러나 가시성도 저하되므로 REST 내에서 선택적 제한 사항입니다.

 

 

 

Rest를 사용할 때 규칙이 있습니다.

 

1. 모든 정보는 URI로 표현한다.

GET을 하던 POST를 하던 DELETE를 하던 같은 데이터의 URI경로는 동일해야 합니다.

ex) GET school/class, POST school/class, DELETE school/class

 

2. 계층관계를 표현할 땐 '/'를 사용합니다.

위 예시 처럼 말이죠.

 

3. 언더바( _ ) 을 사용하지 않고 하이픈( - ) 을 사용합니다.

언더바를 사용하 경우 주소창에 문자가 가려지거나 사용자가 읽을 때 가독성이 떨어질 수 있기 때문입니다.

 

4. 띄어쓰기 금지.

띄어쓰기 또한 가독성을 떨어뜨려 사용자로 하여금 햇갈리게 할 수 있습니다.

 

5. URI의 표현은 소문자로.

 

6. URI에 확장자를 표시하지 않는다.

 

7. URI의 표현은 명사로 한다. 즉, 동사로 하지 않는다.

ex) GET school/class //OK, GET school/study //Fail

 

8. URI 끝에 '/'를 붙이지 않는다.

ex) GET school/class //OK,  GET school/class/    //Fail

 

 

 

 

프로그래머 입장에서 굳이 위 조건을 무시하고 만들 수도 있지만

 

규칙을 무시한 REST가 REST라고 불릴 수 있을까요?

 

 

 

 

아래 링크는 REST의 성숙도 모델 레벨을 설명하는 블로그 입니다. 

좋은 글이니 REST를 설계할 때 참고하시면 좋을 것 같습니다.!!

 

https://brunch.co.kr/@pubjinson/12

 

 

 

※잘못된 정보가 있거나 보충이 필요한 부분이 있다면 피드백을 주시면 감사하겠습니다.