티스토리 뷰

Server

REST의 정체는?

니용 2019. 10. 15. 11:35
반응형

 

Author: 주니용

 

흔히 면접 질문이나 시험 질문에 기본적으로 나온다는 REST, RESTful 방식

프로그래밍 언어가 발달하면서 정말 많은 통신 방식 또한 생기게 되었다.

서버와 클라이언트가 통신하는 방법 중의 하나인 'REST'는 언어마다 하나 이상씩 존재한다고 봐도 무방하다.

 

REST(REprensentational State Transfer)

자원을 이름으로 구분하여 해당 자원의 상태 및 정보를 주고 받는 모든 행위를 의미한다.

구체적으로는 HTTP URI로 자원을 명시하고 Method로 해당 데이터를 어떻게 소화할지 의미하는 척도를 정한다.

URI(Uniform Resource Identifier): 흔히 말하는 URL의 상위 개념으로 인터넷에 있는 자원을 나타내는 유일한 주소이다.

이 주소의 형태는 'schema':'//'[username[:password]@]host[:port]'/[/path][?query][#fragment] 를 나타내는데

 

이를 알려면 위의 용어들이 무얼 뜻하는지 먼저 파악해야 한다. (알게 참 많다)

1. 스키마는 http / https의 구분이다 (https는 HTML5 보안이 적용된 개발 지침방안)

2. username은 사용자명(보통 메일주소에서 많이 사용), password는 선택

3. []의 의미는 생략 가능

4. host는 도메인(예를 들어 다음이면 daum.net), port는 http에서 열려있는 포트 번호(통로 역할)

 

이고 /path 아래 부분부터는 우리가 다뤄볼 REST를 정의할 수 있는 구간이다

근데 Method를 아직 안했다!

 

Method: 자원을 어떤 용도로 사용할 것인지 한눈에 알아보도록 구분한 것

[POST, GET, PUT, DELETE]로 나뉘는데 순서대로 [입력, 조회, 수정, 삭제]의 대표주자로 본다.

근데 자주 사용하는 것은 [POST, GET] 2가지이다.

 

보통 REST의 규칙은 /path?queryString(Map 형식)#fragment 라고 되어 있는데,

fragment는 보통 클라이언트에서 많이 사용하므로 지금 여기서는 /path?query 부분만 다뤄보려고 한다.

 

예를 들어, 도로명 주소를 조회하고 입력하는 API를 만들어보고 싶다고 하자.

주소의 의미를 담아 path는 '/address'라고 하고

보통 시/군/구 & 동/읍/면 으로 구분되는데 이를 depth 별로 쪼개어 정의하면

Method(GET) : /address/search?city=seoul&town=mapogu
Method(POST) : /address/insert?city=gyeonggi&town=yongin

 

행위를 문장형으로 표현한 것 같이 정리해서 한 눈에 금방 알아볼 수 있을거 같고,

이러한 이유때문에 사람들은 RESTful 방식의 표현 방법을 선호한다.

 

여기서 설계 규칙이 있는데 간단히 정리하면 아래와 같다.

 

규칙

1. 슬래쉬(/)는 계층을 나타낸다.

2. 마지막에 '/'를 사용하지 않는다.

3. '-'은 가독성을 높이는데 쓴다.

4. 소문자 사용을 추천한다.

5. 확장자를 사용하지 않는다.

6. 모든 메소드를 POST만 사용하지 않는다.

7. resouce, id외에 다른 파라미터가 유입되는 경우를 가급적 지향한다.

 

당연히 이러한 REST 방식에도 장단점이 존재한다.

 

장점

1. REST API 사용을 위한 별도의 인프라 구축이 필요 없다. 즉, 명세를 안해도 모두의 규약이기 때문에 구분하기 쉽다.

2. 의도하는 바를 쉽게 파악한다. - 위에서 언급

3. HTTP 프로토콜을 따르는 모든 플랫폼에서 사용 가능하다.

4. 서버와 클라이언트의 역할을 명확하게 분리한다.

 

단점

1. 표준이 존재하지 않아 정의하기 모호하다. 주로 API 전용 문서를 따로 제작하여 서버-클라이언트 상호 작용을 한다.

2. 사용 가능한 메소드가 4가지 뿐이다.

3. 일부 구형 브라우저에서 지원하지 않는다.

 

특징

1. 자원을 관리하고 포맷화하는데 강력하다. 관리하는 쪽이 서버이고 요청하는 쪽이 클라이언트로 명확히 구분되고, 서버에서 제공되는 데이터만 클라이언트는 확인 가능하다.

2. HTTP 프로토콜이 무상태성이기 때문에 REST 또한 무상태성을 갖는다.

3. 캐시처리가 가능하여 대량의 요청에 대해 효율적으로 처리가 가능하다. 캐시를 사용하므로 속도도 당연 빠르다.

4. 서버에서 제공하는 URL가 아닌 다른 URL을 호출하면 404에러가 출력된다. (에러는 나중에 다루도록 해보아야겠다.)

5. 다중 계층으로 구성할 수 있어서 로드밸런싱, 암호화, 사용자 인증 등을 추가 가능하다.

6. 인터페이스가 일관성이 있어서 모든 플랫폼에서 사용 가능하다.

 

이렇게 REST 방식을 사용하여 작성된 API를 'REST API'라고 보통 얘기하고, 이러한 웹 서비스를 'RESTful'하다고 할 수 있다.

반응형

'Server' 카테고리의 다른 글

[Java] NPE와 Optional Class  (1) 2019.10.26
[Java] Lambda와 Stream(2)  (0) 2019.10.15
[Java] Lambda와 Stream(1)  (2) 2019.10.15
[Spring] Annotation과 MVC  (1) 2019.09.17
[Spring] Spring Framework & Spring Boot  (1) 2019.09.16
[Spring] Maven vs Gradle  (1) 2019.09.16
댓글
공지사항