라벨이 [HTTP]인 게시물 표시

REST API 설계하는 법

이미지
안녕하세요. 남산돈가스입니다. 지난 포스팅 "REST란?" 에 이어서 REST API를 설계하는 법에 대해서 포스팅하겠습니다. RESTful한 API를 설계하기 위해서 가지고 있어야하는 세가지 특징을 Richardson Maturity Model(이하 RMM)을 가지고 설명드리겠습니다. 위 그림은 RMM 모델을 얘기하는데,  Leonard Richardson가 정의한  REST  방식의   주요   요소들을  3 개의   단계로   나눈   모델 을 의미합니다. REST의 영광(?)을 얻기까지의 레벨을 총 0~3 단계로 표현했는데요.  각 단계 별로 설명드리겠습니다. Level 0 : The Swamp of POX 웹의 기본 메커니즘을 전혀 사용하지 않은 단계로, HTTP Body로 데이터 통신을 하고 있긴하지만 POX(Plain Old XML)로 요청과 응답을 주고받는 RPC(Remote Procedure Call) 스타일의 시스템입니다. HTTP Method는 POST만을 사용하며, 서버로 요청하는 서비스는 그 자체로 하나의 endpoint를 가지게 됩니다.  쉽게 예를들자면, API 요청 도메인이 있고 게시판 기능을 하는 서비스를 만들었다고 한다면, POST /postService(게시판 서비스)와 같이 하나의 endpoint를 가지게 되고 이 endpoint로의 요청 Body의 addPost, getPost 등 필요로 하는 내용을 작성하여 요청을 전달하게 됩니다. 처음에 언급했듯이 HTTP가 제공하는 수많은 기능들을 모두 무시한 채 데이터를 통신하는 용도의 모델입니다. Level 1 : Resources RMM Level 1 에서는 Resources(이하 리소스)를 도입합니다. URI 설계 시 리소스라는 개념을 도입하여 요청을 단일 서비스 endpoint로 보내는 것이 아니라, 각각의 리소스와 통신하게 됩니다. 예를 들어, 기존 /postService 로 모든 요청을 전달한 것에 비해서,

REST란?

안녕하세요. 남산돈가스입니다. 오늘은 REST 란 무엇인가에 대해서 알아보려고 합니다. REST란 Represendtational State Transfer의 약자로 소프트웨어 아키텍처의 한 형식으로 정의되어있습니다. 이 용어는 2000년 로이 필딩(Roy Fielding)의 박사학위 논문에서 처음으로 소개되었습니다. 당시 로이 필딩은 웹(HTTP)이 설계의 우수성에 비해 제대로 사용 되어지지 못하는 모습에 안타까워하며 웹의 장점을 최대한 활용할 수 있는 아키텍처로써 REST를 발표 하였습니다. 그렇다면, REST 하다는 것은 어떤 것을 의미할까요? 제가 이해하기 쉽게 정의한 "REST하다" 는 것은 웹에서 제공하는 모든 자원들에 각자 고유한 URI를 정의해 그 URI만 보더라도 해당 자원들의 명세를 표현하고 이해할 수 있게하는 디자인 방식(?) 방법론(?) 이라고 생각합니다. 따라서 RESTful API는 REST의 설계방식을 반영한 API를 제공한다는 것을 의미할 수 있습니다. 여기서 말한 REST의 구성은 어떤 것이 있는지 알아보겠습니다. REST의 구성 자원의 식별 (Resource) 요청 내에 기술된 개별 자원을 식별할 수 있어야 한다. 웹 기반의 REST 시스템에서의  URI 의 사용을 예로 들 수 있다. 자원 그 자체는 클라이언트가 받는 문서와는 개념적으로 분리되어 있다. 예를 들어, 서버는 데이터베이스 내부의 자료를 직접 전송하는 대신, 데이터베이스 레코드를 HTML, XML이나 JSON 등의 형식으로 전송한다. 메시지를 통한 리소스의 조작  (Verb)  클라이언트가 어떤 자원을 지칭하는 메시지와 특정 메타데이터만 가지고 있다면 이것으로 서버 상의 해당 자원을 변경·삭제할 수 있는 충분한 정보를 가지고 있는 것이다. 자기서술적 메시지  (Representations) 각 메시지는 자신을 어떻게 처리해야 하는지에 대한 충분한 정보를 포함해야 한다. 예를 들어 MIME type과 같은