이번 글에서는 HTTP 웹서비스와 RESTful API 웹 서비스에 대해서 작성해보겠습니다.
REST(Representational State Transfer)는 아키텍처는 하나의 규약이라고 볼 수 있으며, 웹서비스의 사실상 표준입니다.
먼저, 용어에 대해 정리 진행하겠습니다.
Service는 어플리케이션, 노드끼리 데이터를 교환하고 통신을 진행합니다.
그 통신 규약을 HTTP 프로토콜을 사용한다면 이것을 웹서비스라고 할 수 있습니다.
웹 서비스에 대한 표준화 작업이 2000년대 초반에 이뤄졌는데, xml을 통해 공식적인 표준을 SOAP라 할 수 있습니다.
SOAP로 통신을 진행하다보니 더 좋은 방법들이 오픈소스 커뮤니티 중심으로 만들어지게 됩니다.
이것이 REST이며 지금은 사실상의 표준인 REST에 대해 더 잘 사용하고 있는 상황입니다.
SOAP, REST 모두 Web이라고하는 platform 위에서 서비스가 이뤄진단 점에서 같습니다.
또한, HTTP를 전송 규약으로 따르고 있습니다.
그러나 SOAP은 XML 기준으로 진행하며, REST는 JSON이란 포맷을 많이 쓰이고 있습니다.
HTTP
HTTP는 헤더와 바디로 구성됩니다.
바디에 실제 데이터가 담기게 됩니다.
HTTP는 요청시 요청 방식이 정해져있습니다. 요청의 종류로는 8개가 있습니다. (GET,POST,HEAD, TRACE, PUT, DELETE, OPTIONS, CONNECT)
일반적으론, GET, POST를 주로 쓰지만, RESTful API서비스는 PUT, DELETE도 사용합니다.
| Method | Description |
| GET | 자원요청 |
| POST | Entity를 포함한 자원요청 |
| HEAD | HTTP Header 정보만 수신 |
| TRACE | Request의 루프백 테스트 |
| PUT | URL에 자원을 생성 |
| DELETE | URL의 자원을 삭제 |
| OPTIONS | 응답 가능한 HTTP 메소드를 요청 |
| CONNECT | 터널링의 목적으로 연결 요청(프록시에서 사용) |
요청의 주소인 end point는 URL로 구성되어 있습니다. URL은 프로토콜 + 서버 + 리소스로 구성되어 있습니다.
RESTful 기반 웹 서비스
RESTful 웹 서비스는 Roy Fielding 박사 학위 논문에서 제안한 내용으로 이 내용이 사실상의 표준이 되었습니다.
그 당시의 웹은 HTTP1.1(웹 아키텍처)의 우수성을 활용 못하고 있다는 내용으로 논문을 작성했습니다.
공식적인 표준으로 SOAP을 만들었음에도 불구하고 REST 를 사용하는 이유는 '데이터' 때문입니다.
SOAP이 동작과 프로세싱에 집중하는 반면, REST는 데이터 그 자체에 집중하고 이를 처리하는 것에 관심을 갖고 있습니다.
또한, SOAP은 데이터보다는 내부적 프로세스나 보안에 집중하고 있습니다. 그렇기 때문에 기업간 상거래에 사용하고 있습니다.
앞으로 만들어지는 대부분의 서비스들은 RESTful 하게 만들어질 것이 일반적이라 볼 수 있습니다.
Spring은 3.0 이후부터 REST에 대한 지원을 제공하고 그 이후에도 계속되고 있습니다.
RESTful기반 웹서비스는 웹을 기반으로 한 아키텍처로 HTTP를 적극적으로 활용하고 있습니다. (2000년대)
API를 설계하고 운영할 때 RESTful 하다는 의미는 다음을 최소한 포함합니다.
1) API 의 Endpoint가 오직 하나이다.
2) 요청을 GET,POST,PUT,DELETE를 다양하게 사용한다.
3) 요청과 응답에 대한 메타데이터는 HTTP 프로토콜 방식을 사용한다
4) URL 에 동사(verb)를 포함하지 않는다.
지금 만들어지는 대부분의 서비스는 RESTful 하게 만들어지고 있습니다.
* RESTful 하다 = REST API를 제공하는 웹 서비스
대부분의 API 서비스들은 인증을 진행하면서 서비스를 사용하는데, github에서는 인증없이 이를 제공하고 있습니다.
위 사이트에 들어가면 JSON 형태로 사용자들의 정보를볼 수 있습니다.
pom.xml
이제, 다시 spring boot project로 돌아가겠습니다.
pom.xml파일은 maven build tool을 사용하면 추가되는 파일입니다.
저희는 현재 기본적인 프로젝트를 추가했으므로 아래와 같은 dependency를 가진 pom.xml을 볼 수 있습니다.
Web MVC, Spring MVC에 필요한 여러 라이브러리를 포함하는 dependency가 spring-boot-starter-web입니다.
자바에서 스프링프레임워크는 웹과, stand alone에서 사실상 표준으로 사용되고 있습니다.
스프링 MVC와 유사한 프레임워크로써 Strust2가 있지만, 국내에서는 많이 사용되지 않습니다.
루비에서는 Rails 프레임워크가 있고, 파이썬에서는 Django, Flask 가 있습니다.
REST
2000년에 HTTP 프로토콜 저자 중 한명인 Roy Fielding 박사 논문에 소개된 내용으로 HTTP를 보다 HTTP답게 사용하기 위한 방법론입니다.
철저히 리소스 중심적 설계를 진행하고 있습니다.
여기서 말하는 리소스는 데이터라고 생각하셔도 됩니다.
HTTP 메소드를 적극적으로 활용합니다.
데이터를 다룬다는 것은 CRUD를 활용한단 것인데 HTTP 메소드에 빗대자면 아래와 같습니다.
- Create = POST
- Read = GET
- Update = PUT
- Delete = DELETE
REST의 원리와 원칙
- 확장성 있는 웹 서비스를 위한 아키테처적인 접근
- Client-Server로 구성돼야한다
- Stateless여야한다. 즉, 클라이언트 상태를 서버에 저장하지 않아야한다.
- Cacheable: 요청이 같다면 기존의 캐시를 바탕으로 응답 가능하도록 동일 응답이 가야한다.
- Code on demand(optional)
- Uniform interface
1. Client를 Server로부터 분리하라
Client는 모바일, IoT기기 등 다양한 환경을 가지고 있습니다.
Client가 무엇이든간에 Data만으로 응답을 해줍니다.
2. Stateless
서버가 상태를 가지고 있지 않아야합니다.
요청이 같다면 응답또한 같아야한다는 의미입니다.
전통적인 웹서비스는 서버에서 session을 관리합니다. 따라서 stateful합니다.
요청에 대한 client파악을 위해 session을 사용하고 이를 stateful하다고 합니다.
restful api를 사용한다면, session방식을 사용하지 않기 때문에 token 기반의 인증 방식을 사용합니다.
3. Cacheable
어플리케이션적으로 구현한다기 보다는 전체적인 구간마다 cache가 있는데 이를 잘 활용합니다.
웹 어플리케이션 서버, 웹 서버, client 웹 브라우저에 있을 수도 있습니다.
HTTP 에서 cache를 지원하고 있으며, RESTful API에서는 cache 적용을 통해 전박적으로 서비스 성능이 높아집니다.
4. Layered System
인접한 구간끼리만 통신하라는 의미입니다.
client가 server에 접근할 때 firewall, gateway, Load balancer 등 다양한 layer들을 거쳐서 접근하게 됩니다.
5. Code on Demand (optional)
최근에는 잘 쓰이지 않습니다.
서버에서 모든것을 다 실행한다기 보단 client에 실행코드를 내려주고 client에서 실행이 됩니다.
클라이언트의 기능을 일시적으로 확장하거나 커스터마이징이 가능합니다.
Java Applet, JavaScript가 대표적인 예입니다.
이부분은 악성코드가 내려갈 수도 있다는 단점이 있습니다.
SPA라는 기술을 통해 client도 일을 많이 합니다.
서버에서는 data를 client에 내려주기만하고 client에서 이를 가공한다면 이것이 code on demand라 할 수 있습니다.
6. Uniform Interface
URL 주소만 있으면 Client가 어떤 것이든지 서버는 상관없다는 의미입니다.
Client에서 요청하는 대상이 resource가 아닌 representation입니다.
Uniform interface는 4가지로 설명 가능합니다.
- resource identifier: url을 의미
- resource representations: resource를 확장한 개념으로 RESTful에서 중요한 개념
- self-descriptive message
- HATEOAS(Hypermedia As The Engine Of Application State)
6-1. Uniform Interface
URL, URI를 요청의 end point로 쓰겠단 의미입니다.
URL은 굉장한 확장성을 가지고 있습니다.
6-2. Representation
Resourcee는 unique ID 로 하나 이상의 URI뿐만 아니라 다양한 방법으로 설명되는 Representation을 가질 수 있습니다. 어떤 URL을 요청한다는 것은 어떤 Resource를 요청한다는 의미입니다. 여기서 Resource는 단순한 static한 resource를 의미하는 것이 아니라 다시 representation으로 분기합니다.
같은 URL을 요청했다고 하더라도 HTTP 4가지 메소드(POST/GET/PUT/DELETE)에 따라 응답이 다릅니다.
요청은 Resource로 하지만, 응답은 Representation으로 합니다.
*GET method를 통해 Resource, Representation의 차이에 대해 파악해보겠습니다.
GET method의 정의는 아래와 같습니다.
| The GET method request transfer of current selected representation for the target resource. |
--> Target resource 에 대한 현재의 선택된 representation 하나를 반환
--> 리소스는 HTTP요청의 대상이지만, 리소스의 개념을 제한하지 않음
--> 리소스라는 URL은 굉장히 제한되어 있는 개념이지만, 유한한 리소스를 다양하게 활용 가능하다
--> 즉, 하나의 리소스를 통해 다양한 응답을 줄 수 있다
위 그림과 같이 같은 resource를 요청했지만, Content-Language에 따라서 다른 응답이 오고 있습니다.
이처럼 클라이언트와 서버간의 내용 협상을 통해서 응답이 결정 됩니다.
일반적으로 사전 협상에 의해 서버가 선택합니다.
적절한 representation이 존재하지 않는다면 406 Acceptable로 응답합니다.
6-3. Self-Descriptive message & API
REST 는 상태가 없기 때문에 client로부터 요청이 올때마다 새로운 요청이 오게 됩니다.
응답할 때도 마지막 응답이 됩니다.
따라서, client 측에서 요청할 때 서버에 충분한 설명적인 메시지를 전달해야하며 서버에서도 설명적인 응답이 필요합니다.
6-4. HATEOAS (Hypermedia As The Engine Of Application State)
RESTful 서비스 대부분이 이를 구현하고 있진 않습니다.
이를 적용해야만 RESTful API라고 인정할 수도 있겠지만, 적용하지 않아도 서비스 제공에는 큰 무리가 없습니다.
사용자가 웹 서비스를 활용할 때, 요청한 데이터 이외의 다른 링크, 메뉴 등 해당 데이터와 관련된 링크들이 같이 옵니다.
"데이터도 서비스하지만, 이와 관련된 link들을 같이 보내주자"
즉, HTTP 응답에 다음 Action이나 관계되는 리소스에 대한 HTTP Link를 함께 리턴해주자는 의미입니다.
'Java' 카테고리의 다른 글
| Content-Type (0) | 2020.07.14 |
|---|---|
| API Security & JWT (0) | 2020.03.08 |
| JUnit Test (0) | 2020.01.05 |
| Spring Security (0) | 2019.12.30 |
| Read (0) | 2019.11.27 |
