테크레터 3편. 누가 Restful API 소리를 내었는가
이번 주제는 Restful API입니다. API는 많이 들어보셨을텐데 Restful이라는 단어는 생소하실 것 같네요.
💡들어가기전에
API란?
: 일반적으로 웹 서비스를 개발할때, 프론트엔드와 백엔드 개발자간 정해놓은 통신 규칙에 따라 요청&응답이 이뤄질수 있도록 설계해야합니다. 이때 서로 통신할 수 있도록 하는 규칙 집합을 API 라고 합니다.
즉, 클라이언트와 리소스(DB) 간 게이트웨이 역할을 한다고 이해하시면 됩니다.
1. RESTful하다는 건 무슨 뜻인가?
REST(Representational State Transfer) 기반의 아키텍처 스타일을 고수하여 웹 서비스 개발하는 방식입니다. 일반적으로 아래 조건을 만족하면서 엄격하게 설계된 API를 RESTful API라고 말합니다.
*이번 게시글에서는 노란색 음영부분만 집중적으로 다룹니다.
- Client–server architecture
- Statelessness
- Cacheability
- Layered system
- Code on demand (optional)
- A uniform interface
is fundamental to the design of any RESTful system. It simplifies and decouples the architecture, which enables each part to evolve independently. The four constraints for this uniform interface are:
- Resource identification in requests → (~/member/{member_id})
- Resource manipulation through representations
- Self-descriptive messages
- Hypermedia as the engine of application state (HATEOAS)
우선 Uniform Interface가 왜 필요한가를 이해해야 합니다. 사실 이미 접해봤을 겁니다. 하나의 웹 서비스를 구축한다고 할때, 사용성과 UI에 집중하는 클라이언트와 DB데이터와 비즈니스 로직을 다루는 서버로 나눕니다. 현재 우리는 당연하게 클라이언트와 서버를 각각 독립적으로 분리해서 개발하고 있습니다.
근데 처음엔 개념적으로 완벽하게 분리되지 않았습니다. 그래서 둘 중 하나의 기능이 변경될때마다 각각의 코드를 수정해서 둘다 업데이트를 진행해야했죠. 그러나 클라이언트 변경없이도 서버 기능을 언제든지 확장하고 싶었고, 지금의 RESTful 시스템이 등장하게 된 배경이 되었습니다.
최종적으로 uniform Interface를 준수해야 서버와 클라이언트 간 독립적인 개발이 가능합니다.
그렇다면 좀더 디테일하게 살펴보겠습니다.
2-1. Self-descriptive messages
클라이언트가 이해하고 동작을 수행하는데 메세지 자체에 충분한 정보를 제공되어야함을 의미합니다. 예를 들어, 클라이언트에게 반환되는 컨텐츠 유형이 무엇인지 알려주는 Content-type 헤더 정보 등을 포함하고 있어야 합니다.
메세지가 명확하다면 서버나 클라이언트에 기능 변경이 발생해도 동작을 수행하는데 이상없을 겁니다.
2-2. Hypermedia as the engine of application state (HATEOAS)
하이퍼링크를 통해 애플리케이션 상태가 변경되어야 함을 뜻합니다. 최근에는 클라이언트와 서버간 데이터교환을 xml이 아닌 json형태로 많이 사용합니다. spring에서의 json형태로 하이퍼미디어처리 방식은 아래의 예시와 같습니다. (상세)
{
"_links": {
"item": [
{ "href": "https://myhost/cart/42" },
{ "href": "https://myhost/inventory/12" }
]
},
"customer": "Dave Matthews"
}
💡 To the deep
회사 정책에 따라 서비스 변경(계절 프로모션)이 발생되었다고 가정해보죠. 서버에서 링크를 수정해도 href로 클라이언트가 동작한다면, 문제없이 적용 가능합니다.
이젠 실습 코드를 통해 Restful 시스템을 이해해봅시다.
3. 코드부분
추가 작성 예정/링크유첨
4. SOAP API Vs. REST API (참고)
과거의 레거시 시스템들은 SOAP API로 개발되었는데요. 아래 표 확인 바라며 상세 내용은 유첨링크 참조하시기 바랍니다.