REST / REST API / RESTful 간단히 정리

 

REST

지금까지는 간단하게 REST 란 서버의 응답이 JSON 형식일 때, 혹은 주소에 명사를, 요청방식에 동사를 사용해 의도를 명확하게 하는 것 이라 정의했다.

 

조금 더 정확하게 설명하자면

REST(Representational State Transfer) 란
웹에 존재하는 모든 자원에 고유한 URI 을 부여하여 활용하는 것을 의미한다.
자원을 구분하여 해당 자원의 상태/정보를 주고 받는 모든 것을 의미한다.

 

라고 할 수 있다.

여기서 말하는 자원에는 이미지, 동영상, DB 등이 있다.

 

- HTTP URI 을 통해 자원 명시.
- HTTP Method(POST, GET, PUT, DELETE) 를 통해 해당 자원에 대한 CRUD operation 적용

 

1. Resource (자원)
   자원은 Server 에 존재하고, 모든 자원은 고유 ID 를 갖는다.
   자원을 구별하는 각각의 ID 는 HTTP URI 이다.
   
   
2. Method (행위)
   지정한 자원을 조작하기 위해 HTTP 프로토콜을 사용하는 것.
   HTTP 프로토콜은 POST, GET, PUT, DELETE 등의 메소드를 제공한다.
   - POST를 통해 URI를 요청하면 리소스를 생성한다.
   - GET을 통해 해당 리소스 조회, 이후 자세한 정보 가져온다.
   - PUT을 통해 해당 리소스를 수정한다.
   - DELETE를 통해 해당 리소스를 삭제한다.
   
   
3. Representation (표현)
   클라이언트가 서버로 요청을 보냈을 때 응답 자원의 상태
   JSON, XML, RSS 등 여러 형태로 나타낼 수 있다.

 

---

 

REST API

REST 를 기반으로 API 를 구현한 것을 말한다.

HTTP 표준을 기반으로 구현하므로 HTTP 를 지원하는 언어로 클라이언트와 서버를 구축할 수 있다.

 

REST 원리/특징에는 다음의 6가지가 있다.

1. Server-Client : 서버-클라이언트 구조
   클라이언트는 유저와 관련된 처리를, 서버는 REST API를 제공함으로써 각각의 역할이 확실하게 구분, 분리되어 작동
2. Stateless : 무상태
   REST는 HTTP의 특성을 이용하기 때문에 무상태성을 갖는다. 상태정보를 기억할 필요가 없고 들어온 요청에 대해서만 처리하면 된다.
3. Cacheable : 캐시 처리 가능
   캐시사용을 통해 응답시간이 빨라지고 REST Server 트랜잭션이 발생하지 않아 응답시간과 성능, 자원이용률을 향상시킨다.
4. Layered System : 계층화
   클라이언트와 서버가 분리되어있기 때문에 중간에 프록시 버서, 암호화 계층 등 중간매체를 사용할 수 있어 자유도가 높다.
5. Self-Descriptiveness : 자체 표현 구조
   JSON을 이용한 메세지 포멧을 이용해 직관적 이해가 가능하고 REST API만으로도 요청이 어떤 행위인지 알 수 있다.
6. Uniform Interface
   HTTP 표준에만 따른다면 모든 플랫폼에서 사용이 가능하며, URI로 지정한 리소스에 대한 조작을 가능하게 하는 아키텍쳐 스타일을 말한다.
   즉, 특정 언어나 기술에 종속되지 않는다.

 

REST에서의 중심 규칙

• URI는 정보의 자원을 표현해야 한다.
• 자원에 대한 행위는 HTTP Method로 표현한다.

그 외 세부규칙

• URI는 동사보다는 명사를, 대문자보다는 소문자를 사용
  http://example01.com/Running/  ->  http://example01.com/run/  
• 마지막에 '/'를 포함하지 않는다.
  http://example01.com/test/  ->  http://example01.com/test
• '_' 대신 '-'를 사용한다.
  http://example01.com/test_blog  ->  http://example01.com/test-blog  
• 파일 확장자는 URI에 포함시키지 않는다.
  http://example01.com/photo.jpg  -> http://example01.com/photo  

 

 

---

 

RESTful

REST 원리를 준수하여 REST API를 제공하는 웹 서비스를 RESTful하다고 한다.

 

RESTful 개발원칙

• 자원을 식별할 수 있어야 한다.
  URI만으로도 내가 어떤 자원을 제어하려고 하는지 알 수 있어야 한다.
  이를 위해 Server가 제공하는 정보는 JSON이나 HTTP body 부분에 포함시켜 전송한다.

• 자기서술적이어야 한다.
  데이터의 메타데이터만 보고도 어떤 데이터인지, 어떤 어플리케이션을 실행해야 하는지 알 수 있어야 한다.
  즉, 데이터 처리를 위해서 데이터 원본을 읽어야 한다면 자기서술적이지 못하다.

• 행위는 명시적이어야 한다.
  REST는 아키텍쳐나 방법론의 일종이기 때문에 강제적이지 않다.
  기존처럼 GET과 POST만으로 CRUD를 모두 처리할 수도 있지만 그렇게 할 경우 REST를 따른다고 할 수 없다.

https://www.joinc.co.kr/w/man/12/rest/about

 

Todo List 기능을 구현한다고 가정할 때 RESTful API 표준

endpoint	기능
GET /todos	todo list들
POST /todos	새로운 todo
GET /todos/:id	해당 id의 todo
PUT /todos/:id	해당 id의 todo 수정
DELETE /todos/:id	해당 id todo와 item 삭제
GET /todos/:id/items	해당 id todo item
PUT /todos/:id/items	해당 id todo item 수정
DELETE /todos/:id/items	해당 id todo item 삭제

 

 

---

 

REST의 한계/단점들

• REST는 point-to-point 통신모델을 기본으로 한다. 따라서 서버와 클라이언트가 상호작용 해야하는 어플리케이션에는 적당하지 않다.
• REST는 URI, HTTP 이용한 아키텍처링 방법에 대한 내용만을 담고 있다. 따라서 개발자는 통신과 정책에 대한 설계와 구현을 도맡아서 진행해야 한다.
• REST는 설계 원리이기 때문에 HTTP와는 상관없이 다른 프로토콜에서도 구현할 수 있기는 하지만 HTTP에 의존적이라 자연스러운 개발이 힘들다. 다만 REST를 사용하는 이유가 대부분의 서비스가 웹으로 통합되는 상황이기에 큰 단점이 아니게 되었다.
• CRUD 4가지 메소드만 제공한다. 대부분의 일들을 처리할 수 있지만, 4가지 메소드 만으로 처리하기엔 모호한 표현이 있다.

 

 

 

 

 

---

references

https://thxwelchs.github.io/EmbeddedTomcat%EA%B3%BCTomcat%EC%9D%98%EC%B0%A8%EC%9D%B4/

https://velog.io/@courage331/Spring-%EA%B3%BC-Spring-Boot-%EC%B0%A8%EC%9D%B4

https://khj93.tistory.com/entry/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-REST-API%EB%9E%80-REST-RESTful%EC%9D%B4%EB%9E%80

https://brainbackdoor.tistory.com/53

https://www.youtube.com/watch?v=YSsl5-q2BR4