험프리 11월 9일, 2021에 포스트됨 공유하기 11월 9일, 2021에 포스트됨 목차 REST란? REST 정의 REST 제약조건 REST API REST 주요 구성요소 리소스 메소드 메시지 REST API 구현 서버 측(Back-End) 클라이언트 측(Front-End) REST란? REST 정의 REST(Representational State Transfer)는 월드 와이드 웹과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식이다. 이 용어는 로이 필딩(Roy Fielding)의 2000년 박사학위 논문에서 소개되었다. 필딩은 HTTP의 주요 저자 중 한 사람이다. 이 개념은 네트워킹 문화에 널리 퍼졌다. 엄격한 의미로 REST는 네트워크 아키텍처 원리의 모음이다. 여기서 '네트워크 아키텍처 원리'란 자원을 정의하고 자원에 대한 주소를 지정하는 방법 전반을 일컫는다. 간단한 의미로는, 웹 상의 자료를 HTTP위에서 SOAP이나 쿠키를 통한 세션 트랙킹 같은 별도의 전송 계층 없이 전송하기 위한 아주 간단한 인터페이스를 말한다. 이 두 가지의 의미는 겹치는 부분과 충돌되는 부분이 있다. 필딩의 REST 아키텍처 형식을 따르면 HTTP나 WWW가 아닌 아주 커다란 소프트웨어 시스템을 설계하는 것도 가능하다. 또한, 리모트 프로시저 콜 대신에 간단한 XML과 HTTP 인터페이스를 이용해 설계하는 것도 가능하다. 참조: https://ko.wikipedia.org/wiki/REST REST 제약조건 아래 REST 제약조건을 준수하는 웹서비스를 RESTful 하다 한다. 인터페이스 일관성(Uniform interface) : 아키텍처를 단순화하고 분리해 각 부분을 독립적으로 발전 시킬 수 있음 무상태(Stateless) : REST 서버는 작업을 위한 상태정보(세션, 쿠키 등)를 관리하지 않아야 함. 시스템 영향없이 관리 및 업데이트 가능 캐쉬(Cacheable) : HTTP 웹표준으로 HTTP가 가진 캐싱 기능이 적용됨 계층화(Layered system) : 서버를 다중 계층으로 구성될 수 있음. 비지니스 로직을 수행하는 API 서버와 그 앞단에 사용자 인증, 암호화, 로드밸런싱 등의 계층을 추가해 구조상의 유연성 제공 클라이언트/서버 구조 : 클라이언트와 서버가 각각의 역할 구분. 서버는 API를 제공하고 API 요청 시 비지니스 로직 처리와 데이터 저장을 책임. 클라이언트는 사용자 인증, 상태(세션, 로그인 정보)관리와 서버 리소스 요청을 책임지는 구조로 역할 구분(상호 의존성을 줄임) REST API REST 기반으로 서비스 API를 구현한 것을 REST API라고 한다. 최근 메이저 인터넷 서비스 업체와 공공기관 등에서 자사 데이터를 REST 기반 Open API(일명 REST API)로 제공하고 있다. 또한 많은 기업들이 미들웨어를 REST API 웹서비스로 구성해 다양한 클라이언트(윈도우 애플리케이션, 모바일 앱, 웹페이지 등)에게 데이터를 제공하고 있다. REST 주요 구성요소 REST 주요 구성요소는 리소스, 메소드, 메시지 3가지이다. 리소스 : 접근할 대상(자원)을 URI를 통해 식별 메소드 : 리소스에 대한 행위, 표준 HTTP 메소드에 따라 자원에 접근(생성, 조회, 수정, 삭제) 메시지 : HTTP 해더와 바디에 포함된 메시지는 메시지를 처리하기 위한 충분한 정보 포함 즉, REST는 어떤 자원(리소스)에 어떤 행위(메소드)를 어떻게(메시지) 할지 HTTP 기반으로 정해놓은 아키텍처이다. 리소스 리소스 의미 /books 도서정보 컬렉션(목록) /books/1 1번 도서의 정보 /books/1/photo 1번 도서의 사진 리소스는 URI 중 경로를 통해 정의한다. 리소스 정의를 통해 접근할 자원을 표현한다. 리소스명은 동사보다 명사를 활용해 어떤 자원인지 표현하는데 집중해야 한다.(/getBook/?id=1 보다 /books/1/이 적합) 슬래시(/)로 자원의 계층 관계를 나타내며, 앞쪽부터 넓은 의미로 사용한다. /(컬렉션/(아이템)/(컬렉션)/(아이템) (예> /sports/soccer/player/1) 메소드 REST에서는 메소드를 통해 리소스에 대한 행위를 정의한다. 표준 HTTP 메소드 중 Get, Post, Put, Delete를 통해 자원의 CRUD를 정의한다. HTTP 메소드 자원에 대한 행위 POST 자원 생성(Create) GET 자원 조회(Read) PUT 자원 수정(Update) DELETE 자원 삭제(Delete) 엔드포인트(Endpoint) 리소스와 메소드를 조합한 것을 엔드포인트라하며, 자원에 대해 어떤 행위를 할것인지를 정의한 것이다. 메소드 리소스 엔드포인트 행위 POST /books 새로운 도서정보 생성 GET /books 도서정보 목록 조회 GET /books/1 1번 도서정보 상세 조회 PUT /books/1 1번 도서정보 수정 DELETE /books/1 1번 도서정보 삭제 메시지 자원에 대한 정보는 HTTP 바디와 HTTP 해더, 응답 상태코드를 활용한다. HTTP 바디 HTTP 바디에 포함된 데이터를 통해 자원에 대한 정보를 전달한다. 데이터 포맷으로는 최근 JSON을 많이 사용하는 추세이며, XML과 사용자정의 포맷 등을 정해서 사용할 수도 있다. 조회(GET 메소드) 요청 시 서버는 조건에 맞는 정보를 HTTP 바디에 담아 클라이언트에 응답한다. 생성(POST 메소드), 수정(PUT 메소드) 요청 시 클라이언트는 자원에 대한 정보를 요청 HTTP 바디에 담아 서버에 요청한다. HTTP 해더 HTTP 해더에는 HTTP 바디의 컨텐츠 종류를 명시할 수 있다. 해더에 정의된 컨텐츠 타입에 따라 데이터를 분석한다. 요청 HTTP 해더는 "Accept" 항목으로, 응답 HTTP 해더는 "Content-type"으로 컨텐츠 타입을 설명한다. 자주사용하는 컨텐츠 타입 application/json application/xml text/plain image/jpeg image/png 자세히 보기 : https://ko.wikipedia.org/wiki/미디어타입 응답 상태코드 리소스 요청에 대한 응답은 응답 상태코드로 설명할 수 있다. 대표적인 응답 상태코드 200 - 요청을 정상 수행 201 - 리소스 생성 요청 성공(Post로 생성 요청 시에 한함) 400 - 요청이 부적절함 401 - 인증되지 않은 상태에서 보호된 리소스 요청 403 - 공개되지 않은 리소스에 접근 요청(인증과 무관) 404 - 존재하지 않는 리소스 요청 406 - 지원하지 않는 미디어타입을 요청 409 - 리소스 상태에 의해 해당 요청을 수행하지 못함 자세히 보기 : https://ko.wikipedia.org/wiki/HTTP_상태_코드 REST API 구현 REST API는 HTTP 웹표준 기반으로 제작하므로, HTTP 라이브러리를 갖는 모든 언어 및 개발 도구로 구현할 수 있다. 델파이/C++빌더 기준으로 다음 기술을 이용해 REST API를 개발(구현)할 수 있다. 서버 측(Back-End) RAD Server - 백-엔드 기능을 기본 제공하는 턴키 방식 솔루션, 패키지(모듈) 개발해 REST 엔드포인트 손쉬운 확장이 큰 장점 WebBroker - RAD 스튜디오(델파이, C++빌더) 웹 개발 프레임워크 DataSnap - RAD 스튜디오 멀티티어 개발 프레임워크, TCP/IP, HTTP 프로토콜 제공 Delphi MVC Framework - 써드파티(오픈소스) 웹서비스 개발 프레임워크 mORMot - 써드파티(오픈소스), SOA, ORM 개발 프레임워크 클라이언트 측(Front-End) REST Client - REST 클라이언트 프레임워크 Net HTTP Client - 네이티브 HTTP 클라이언트 프레임워크 Indy Library - 범용 네트워크 라이브러리(HTTP 클라리언트, 서버 제공) 인용하기 이 댓글 링크 다른 사이트에 공유하기 더 많은 공유 선택 사항
Recommended Posts
이 토의에 참여하세요
지금 바로 의견을 남길 수 있습니다. 그리고 나서 가입해도 됩니다. 이미 회원이라면, 지금 로그인하고 본인 계정으로 의견을 남기세요.