REST, REST API, RESTful API 란 ?

서론 

 

안녕하세요. is낫널입니다. 

오늘은 이력서를 계속 넣다보니, 채용공고에서 자주 보았던 단어를 알아보게 되었습니다. 

7개월이란 시간을 국비학원을 다녔지만, 그럼에도 불구하고 부족한 부분은 아직 넘쳐나는 것 같습니다. 

이번에 해당 개념을 공부하게 되면서 이 기술을 프로젝트에 적용하고 싶네요. 

오늘도 글 보러 와주신 분들께 미리 감사의 말씀을 전합니다 :) 

 

본론 

 

REST 란?

REST(Representational State Transfer)의 약자로 자원을 이름으로 구분하여 해당 자원의 상태를 주고받는 모든 것을 의미합니다.

즉, 간단하게 말하자면 자원의 표현에 의한 상태를 전달하는 것을 말합니다.

• 자원 : 해당 소프트웨어가 관리하는 모든 것을 말합니다.
  • 자원(Resource) : HTTP URI
• 자원의 표현 : 그 자원을 표현하기 위한 이름을 말합니다.
  • 예를 들어, DB의 과목 정보가 자원일 때, ‘subject’ 를 자원의 표현으로 정합니다.
  • 자원에 대한 행위(Verb) : HTTP Method
• 상태(정보)전달
  • 데이터가 요청되는 시점에 자원의 상태(정보)를 전달합니다.
  • JSON 혹은 XML을 통해 데이터를 주고받는 것이 일반적입니다.
  • 자원에 대한 행위의 내용(Representations) : HTTP Message Pay Load

[Pay Load]

Pay Load : 전송되는 데이터를 의미합니다.

예를 들어, 택배 보내고 받을 때, 택배물건이 전송되는 물건 그 자체인 것으로 Pay-Load 가 되고, 송장이나 박스, 뽁뽁이와 같은 완충재 등은 부가적인 것이기 때문에 Pay-Load라고 말하지 않습니다.

 

기본적으로 REST는 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에

웹의 장점을 최대한 활용할 수 있는 아키텍처 스타일입니다.

또한 네트워크 상에서 Client와 Server 사이의 통신 방식 중 하나라고 할 수 있습니다.

 

 

정리하자면, REST 란

1. HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고,
2. HTTP Method(POST, GET, PUT, DELETE, PATCH 등)를 통해
3. 해당 자원(URI)에 대한 CRUD Operation을 적용하는 것을 의미합니다.

 

[CRUD Operation]

CRUD Operation 이란

컴퓨터 소프트웨어가 가지는 기존적인 데이터 처리기능인 Create, Read, Update, Delete를 묶어서 일컫는 말인 CRUD 인 Operation 동작예시는 다음과 같습니다.

 

Create : 데이터 생성(POST)
Read : 데이터 조회(GET)
Update : 데이터 수정(PUT, PATCH)
Delete : 데이터 삭제(DELETE)

 

 

 

REST의 특징

1. Server-Client(서버-클라이언트 구조)
   • REST Server : API를 제공하고 비즈니스 로직 처리 및 저장을 책임집니다.
   • Client : 사용자 인증이나 context(세션, 로그인 정보) 등을 직접 관리하고 책임집니다.
   ⇒ 이로 인해, 서로 간 의존성이 줄어드는 특징이 있습니다.
2. Stateless(무상태)
   • HTTP 프로토콜은 Stateless Protocol 이므로 REST 역시 무상태성을 갖습니다.
3. Cacheable(캐시 처리 가능)
   • 웹 표준 HTTP 프로토콜을 그대로 활용하기 때문에 웹에서 사용하는 기존의 인프라를 그대로 활용할 수 있습니다.
     즉, HTTP 가 가진 가장 강력한 특징 중 하나인 캐싱 기능을 적용할 수 있습니다.
4. Layered System(계층화)
   • REST Server는 다중 계층으로 구성될 수 있습니다.
5. Uniform Interface(인터페이스 일관성)
   • URI로 지정한 Resource에 대한 조작을 통일되고 한정적인 인터페이스로 수행합니다.
   • HTTP 표준 프로토콜에 따르는 모든 플랫폼에서도 사용이 가능합니다.
   • 즉, 특정언어나 기술에 종속되지 않습니다.

 

REST의 장단점

 

• 장점
  • HTTP 프로토콜의 인프라를 그대로 사용하기 때문에 REST API 사용을 위한 별도의 인프라를 구축할 필요가 없습니다.
  • HTTP 프로토콜의 표준을 최대한 활용하여 여러 추가적인 장점을 함께 가져갈 수 있게 해 줍니다.
  • HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능합니다.
  • Hypermedia API의 기본을 충실히 지키면서 범용성을 보장합니다.
  • REST API 메시지가 의미하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악할 수 있습니다.
  • 여러 가지 서비스 디자인에서 생길 수 있는 문제를 최소화합니다.
  • 서버와 클라이언트의 역할을 명확하게 분리합니다.
• 단점
  • 표준이 존재하지 않아서 정의가 필요합니다.
  • 사용할 수 있는 메서드가 4가지 밖에 없습니다.
    • HTTP Method 형태가 제한적이기 때문입니다.
  • 브라우저를 통해 테스트할 일이 많은 서비스라면
    쉽게 고칠 수 있는 URL보다 Header 정보의 값을 처리해야 하므로 전문성이 요구됩니다.
  • 구형 브라우저에서 아직 제대로 지원해주지 못하는 부분이 존재합니다.
    (예를 들어, 익스플로러)

 

REST API 란?

REST API는 REST의 원리를 따르는 API를 의미합니다.

 

[API]

API : 데이터와 기능의 집합을 제공하여 컴퓨터 프로그램 간 상호작용을 촉진하며, 서로 정보를 교환가능하도록 하는 것을 말합니다.

 

 

REST API 설계 규칙

 

1. URI는 동사보다는 명사를, 대문자보다는 소문자를 사용하여야 합니다.

GET  /Students/1 →  GET  /students/1

  

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

http://restapi.example.com/test/ → http://restapi.example.com/test

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

http://restapi.example.com/test_example → http://restapi.example.com/test-example

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

http://restapi.example.com/test.jpg → http://restapi.example.com/test

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

     - URI에 HTTP Method 가 들어가면 안 됩니다.

GET  /students/delete/1 →  DELETE  /students/1

    - URI 에 행위에 대한 동사 표현이 들어가면 안됩니다. 

GET  /students/show/1 → GET  /students/1

 

 

 

RESTful 이란?

RESTful 은 REST의 원리를 따르는 시스템을 의미합니다.

이러한 의미가 탄생하게 된 이유는 REST를 사용했다 해서, 모두가 RESTful 한 것은 아니기 때문입니다. REST API라고 말하는 API를 보면, REST의 원리를 정확하게 따르는 API는 거의 없다는 것을 알 수 있습니다. 특히 REST 의 특징 5번에 해당하는 인터페이스 일관성의 제약조건에 해당하는 self-descriptive messages와 hypermedia as the engine of application state(HATEOAS)를 잘 만족시키지 못합니다.

• self-descriptive messages : 자기 서술적 메시지라고도 하는 해당 제약조건은 각 메시지가 자신을 어떻게 처리해야 하는지에 대한 충분한 정보를 포함해야 하는 것을 의미합니다.
• HATEOAS : 클라이언트가 관련된 리소스에 접근하기를 원한다면, 리턴되는 지시자에서 구별될 수 있어야 한다는 것을 의미합니다.
  • 예로, 충분한 콘텍스트 속에서의 URI를 제공해 주는 하이퍼텍스트 링크를 들 수 있습니다.

그래서 예전에는 REST API에서 REST의 원리가 잘 지켜지지 않는 API 에 대해 REST라고 할 때, REST를 개발한 Roy Fielding(로이 필딩) 은 “REST의 원리를 따르지 않고 있다면, REST 말고 다른 이름을 사용해 달라”라고 아래 사진과 같이 트위터에 생각을 밝힌 바가 있습니다.

출처 : https://www.youtube.com/watch?v=RP_f5dMoHFc&t=7s

그래서 이를 반영하여 REST API의 설계규칙을 올바르게 지킨 시스템을 RESTful이라고 부르게 된 것입니다.

 

 

 

마무리 

 

유튜브에서 해당 링크를 통해 REST의 유래를 알 수 있었고, 유독 더 재밌게 공부했었던 것 같습니다. 

발표한 분께서 쉽게 풀어서 설명해 주신 것도 있었지만 47분이 되는 시간을 처음부터 끝까지 흥미진진하게 봤던 것 같아요. 

또한 해당 영상을 보면서 저도 이후에 취직을 하게 되고 1인분을 할 수 있는 개발자로 성장하게 된다면 어떠한 기술에 대해 자신의 생각을 발표할 줄 아는 사람으로 성장하고 싶다는 자극을 받았던 것 같습니다. 

 

그럼 오늘도 좋은 하루 보내시길 바랄게요 :) 

읽어주셔서 감사합니다. 

 

 

 

[References]

그런 REST API로 괜찮은가

 

[네트워크] REST API란? REST, RESTful이란?

 

[Network] REST란? REST API란? RESTful이란? - Heee's Development Blog

 

REST - 위키백과, 우리 모두의 백과사전

유튜브를 제외하고 순서대로 히진쓰님의 서버사이드 기술블로그와 HeeJeong Kwon 님의 기술블로그, 위키피디아를 참고하여 글을 작성하였습니다.