REST
지금까지는 간단하게 REST 란 서버의 응답이 JSON 형식일 때, 혹은 주소에 명사를, 요청방식에 동사를 사용해 의도를 명확하게 하는 것 이라 정의했다.
조금 더 정확하게 설명하자면
REST(Representational State Transfer) 란
웹에 존재하는 모든 자원에 고유한 URI 을 부여하여 활용하는 것을 의미한다.
자원을 구분하여 해당 자원의 상태/정보를 주고 받는 모든 것을 의미한다.
라고 할 수 있다.
여기서 말하는 자원에는 이미지, 동영상, DB 등이 있다.
- HTTP URI 을 통해 자원 명시.
- HTTP Method(POST, GET, PUT, DELETE) 를 통해 해당 자원에 대한 CRUD operation 적용
- Resource (자원)
자원은 Server 에 존재하고, 모든 자원은 고유 ID 를 갖는다.
자원을 구별하는 각각의 ID 는 HTTP URI 이다. - Method (행위)
지정한 자원을 조작하기 위해 HTTP 프로토콜을 사용하는 것.
HTTP 프로토콜은 POST, GET, PUT, DELETE 등의 메소드를 제공한다.
- POST를 통해 URI를 요청하면 리소스를 생성한다.
- GET을 통해 해당 리소스 조회, 이후 자세한 정보 가져온다.
- PUT을 통해 해당 리소스를 수정한다.
- DELETE를 통해 해당 리소스를 삭제한다. - Representation (표현)
클라이언트가 서버로 요청을 보냈을 때 응답 자원의 상태
JSON, XML, RSS 등 여러 형태로 나타낼 수 있다.
REST API
REST 를 기반으로 API 를 구현한 것을 말한다.
HTTP 표준을 기반으로 구현하므로 HTTP 를 지원하는 언어로 클라이언트와 서버를 구축할 수 있다.
REST 원리/특징에는 다음의 6가지가 있다.
- Server-Client : 서버-클라이언트 구조
클라이언트는 유저와 관련된 처리를, 서버는 REST API를 제공함으로써 각각의 역할이 확실하게 구분, 분리되어 작동 - Stateless : 무상태
REST는 HTTP의 특성을 이용하기 때문에 무상태성을 갖는다. 상태정보를 기억할 필요가 없고 들어온 요청에 대해서만 처리하면 된다. - Cacheable : 캐시 처리 가능
캐시사용을 통해 응답시간이 빨라지고 REST Server 트랜잭션이 발생하지 않아 응답시간과 성능, 자원이용률을 향상시킨다. - Layered System : 계층화
클라이언트와 서버가 분리되어있기 때문에 중간에 프록시 버서, 암호화 계층 등 중간매체를 사용할 수 있어 자유도가 높다. - Self-Descriptiveness : 자체 표현 구조
JSON을 이용한 메세지 포멧을 이용해 직관적 이해가 가능하고 REST API만으로도 요청이 어떤 행위인지 알 수 있다. - 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를 따른다고 할 수 없다.
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://brainbackdoor.tistory.com/53
https://www.youtube.com/watch?v=YSsl5-q2BR4
'[Spring] > Spring 정리' 카테고리의 다른 글
| Spring 과 Spring Boot 의 차이 (0) | 2022.10.09 |
|---|---|
| API - 3 (PUT, DELETE) (0) | 2022.09.21 |
| API - 2 (GET, POST) (0) | 2022.09.21 |
| DTO (2) | 2022.09.19 |
| JPA - 2 /CRUD로 행복회로 돌려보기(실습) (0) | 2022.09.18 |