Restful api

서버와 통신하는 어플을 개발 하다보면 Rest api에 대해 알게 되고 이를 이용해 개발 하게 됩니다.

 

Restful api를 설계하고 만드는 일은 백엔드 개발자의 몫이지만, 사용하는건 클라이언트 개발자의 몫인거죠.

 

우리가 사용할 서버측의 api가 어떻게 구성되어 있는지 알아야 전반적인 데이터의 흐름을 알 수 있고 용이하게 사용 할 수 있습니다..

 

그럼 시작해보겠습니다.

 

1. Rest란 무엇인가.

 

Representational State Transfer 의 약자입니다.

 

해석하기가 난해한데요, "대표되는 상태 전달" 보다는 "상태의 변화를 표현" 이라 이해하는게 더 다가올 것 같습니다.

2. http 메서드.

 

http 메서드에는 GET, POST 이외에도 PUT, DELETE가 있습니다. (PATCH, OPTION, HEAD, CONNECT, TRACE도 있어요)

 

서버에 자원 요청시 이러한 http 메서드의 의미에 맞게 사용하는 것이 Rest api의 원칙입니다.

 

3. Rest 예제.

 

아무래도 예제를 통해 확인해 보는 것이 이해가 빠를 것 같습니다.

 

POST
1. http://test.co.kr/users

Get
2. http://test.co.kr/users/userId

PUT
3. http://test.co.kr/users/userId
{
	name : 강호동,
    cellphone : 01012345678
}

DELETE
4. http://test.co.kr/users/userId

 

1. POST 메서드를 이용해 유저 정보를 요청하는 api 입니다. 이미 요청에서 해당 api가 무엇을 하는지 충분하게 드러납니다.

 

2. GET 메서드를 이용해 특정 유저의 정보를 요청하는 api 입니다.

 

3. PUT 특정 유저의 정보를 수정하는 api입니다.

 

4. 이제는 설명이 무의미해 보이네요.

 

4. Rest 특징.

 - Uniform Interface 

어떤 플랫폼에서도 사용 가능합니다. 웹에서건 안드로이드에서건 어떤 http통신에서건 사용 가능합니다. 주고 받는 데이터의 형태에 차이가 있을 뿐이죠.

 

 - Stateless

각 요청은 어떠한 상태에도 연관되어 있지 않습니다. 세션정보를 물고 있지도, 쿠키 정보를 관리하지도 않습니다. 이전 요청의 상태에도 영향을 받지 않고 이후 요청에도 영향을 주지 않습니다. 심플하게 요청을 수행하고 응답할 뿐입니다.

 

 - Cacheable

캐싱이 가능합니다. 대규모의 데이터 처리시 캐시에 담긴 값을 사용 할 수 있습니다.

 

- Self-Descriptiveness

그냥 api만 보아도 뭐 하는 친구인지 알 수 있습니다. 협업이 쉬워집니다.

 

- Client-Server Architecture

자원요청은 클라이언트가, 자원 관리와 로직 처리는 서버가. 지금은 당연하지만, 예전에는 이렇지 못한 경우가 많았지요.

 

- Layered System

클라이언트는 요청만 할 뿐이지만 서버에서는 해당 요청을 처리하기 위해 다양한 레이어로 구성될 수 있습니다. 인터셉터에서 권한 처리도 해야 할 것이고, 로드 밸런싱이나, 보안처리등을 해야지요. 물론 클라이언트는 그저 요청할 뿐입니다.