1. HTTP에서의 Representation
- HTTP GET 메서드의 정의 The GET method requests transfer of a current selected representation for the target resource.target resource에 대한 현재의 선택된 representation 하나를 반환함.
-
- target resource : URI가 가리키는 리소스 = HTTP 요청의 대상(정적 리소스+동적 리소스)
- representation : 어떤 리소스의 특정 시점 상태(state)를 반영하고 있는 정보
- 구성
- representation data
- representation metadata
- cf) 여기서의 상태(state) : 리소스의 상태를 뜻함. 애플리케이션의 상태가 아님 = 웹 애플리케이션이 웹 페이지 A를 렌더링→B를 렌더링하는 것으로 바뀐 것과 같은 종류의 것
- 구성
- 선택된 : 하나의 리소스의 현재 representation이 하나 이상이 될 수 있으며 그 중 하나가 선택되었음을 의미
- 선택 방법
- 클라이언트와 서버간의 내용 협상(Content negotiation)에 따라
- 선택 주체
- 사전협상(proactive negotiation) : 서버가 선택
- “여러 리소스 중 하나가 선택되었다”라고 말할 수 없는 이유 : “안녕하세요”든 “hello”든 모두 uri가 동일하기 때문이다. uri가 동일하다면 같은 리소스이다. ⇒ 여러 리소스 중 하나가 선택된 것이 아니다. (애초에 같은 리소스 내에서 선택되는 것...이라고 생각)
- 사후협상(reactive negotiation) : 서버가 URI 목록을 주면 클라이언트가 선택
- “여러 리소스 중 하나가 선택되었다”라고 말할 수 있는 이유 : 선택지마다 uri가 각각 다를 것이므로 클라이언트가 리소스들 중 하나를 선택한다고 표현해도 무방할지도 모른다. (자세한 것은 HTTP 명세 참고)
- 사전협상(proactive negotiation) : 서버가 선택
- 선택 방법
- EX 1.
- metadata를 포함한 representation들의 예영어 사용자를 위한 representation:한국어 사용자를 위한 representation:HTML을 선호하는 영어 사용자를 위한 representation:HTML을 선호하는 한국어 사용자를 위한 representation:“greeting” 리소스의 현재 representation은
- 영어 사용자를 위한 “hello” , 한국어 사용자를 위한 “안녕하세요” , HTML 문서를 원하는 클라이언트를 위한 “<html><body>hello</body></html>” 등 여러가지가 될 수 있는데 이들 중 하나가 선택되었다는 의미이다.
Content-Type: text/html; charset=UTF-8 Content-Language: ko <html><body>안녕하세요</body></html>
Content-Type: text/html; charset=UTF-8 Content-Language: en <html><body>hello</body></html>
Content-Type: text/plain Content-Language: ko 안녕하세요
Content-Type: text/plain Content-Language: en hello
- 클라이언트가 GET 요청에 “Accept-Language: ko” 헤더를 포함시켜 한국어를 선호함을 밝혔다면 서버는 가장 적절한 representation인 “안녕하세요”로 응답할 것이다. 만약 여기에 “Accept: text/html; charset=UTF-8” 헤더도 포함시켜서 한국어로 되어있고 UTF-8로 인코딩된 HTML 문서를 선호한다고 밝혔다면 “<html><body>안녕하세요</body></html>” representation을 선택하여 응답할 것이다. 만약 적절한 representation이 존재하지 않는다면 406 Not Acceptable로 응답할 것이다.
- ▼ HTTP GET 요청을 서버에 보냄▼ “hello”라는 메시지를 응답으로 받음⇒ https://example.org/greeting 라는 uri를 요청해서 “hello”라는 텍스트 자체인 리소스를 응답으로 받았다. (X) “hello”를 담은 문서인 리소스를 응답으로 받았다. (O))
- ( ∵ “hello” : 리소스가 아니라 representation data “Content-Type: text/plain”, “Content-Language: en” : representation metadata (HTTP 헤더들 전부가 representation metadata에 해당되는 건 X ) 즉, 사실 서버가 보내준 것은 리소스가 아니다.
HTTP/1.1 200 OK Content-Length: 6 Date: Sun, 19 Mar 2017 10:20:47 GMT Last-Modified: Sun, 19 Mar 2017 08:00:00 GMT Content-Type: text/plain Content-Language: en hello
GET https://example.org/greeting Host: example.org Accept: text/plain, text/html; q=0.9 *; q=0.1 Accept-Language: en, ko; q=0.9, *; q=0.1
2. REST에서의 representation
HTTP 명세는 representation이라는 개념을 도입하고 있는데 representation은 바로 REST에서 온 것이다. ( REST——representation 개념——>HTTP )
- Rest 개념 = Representational State Transfer
- State : 웹 애플리케이션의 상태
- 리소스의 상태와 애플리케이션의 상태는 둘 다 동일하게 “state”라는 단어로 표현되고 있긴 하지만 본질적으로 완전히 다른 것이다.(위에서 언급함)
- Transfer : network component 사이에서의 전송 (ex- 서버에서 클라이언트로의 웹 페이지 전송)
- 상태의 전이(transit)를 의미하는 것이 아니다. 사용자가 링크를 클릭함으로써 웹 애플리케이션의 상태가 전이된 것은 사실이지만 그 전이가 아님.
- State : 웹 애플리케이션의 상태
- 즉, 각 자원(Resource)에 대하여 자원의 상태에 대한 정보를 주고받는 개발 방식 ⇒ 특정 시점의 어떤 리소스의 상태(state)를 반영하고 있는 정보를 / 네트워크 컴포넌트 사이에서의(서버←→클라이언트) 전송을 통해 / 웹 어플리케이션의 상태가 바뀌는 개발 방식/아키텍쳐.
- 등장 배경
- HTTP는 GET, POST, PUT, DELETE 등의 다양한 메서드를 지원한다
- 실제로는 서버가 각 메서드의 기본 설명을 따르지 않아도 프로그램을 개발할 수 있다. ( /get정보가져오는서비스, /save저장하는서비스 ... )
- 하지만 저마다 다른 방식으로 개발하면 문제가 될 수 있어 기준이 되는 아키텍처가 필요
- 하나의 URI를 통해 하나의 고유한 리소스(resource)를 대표하도록 설계한단 개념에서 파생
- HTTP는 GET, POST, PUT, DELETE 등의 다양한 메서드를 지원한다
- 구성(HOW TO)
- 자원 (Resource) - URI (ex - /devdange/user) 이용
- 행위 (Verb)- HTTP 메소드 이용
Method 의미 SQL POST Create Insert GET Read Select PUT Update Update DELETE Delete Delete
- 표현 (Representations) - Payload 이용 ( JSON, XML ..)
- 잘 표현된 HTTP URI로 자원(Resouce)를 정의하고 데이터를 JSON/XML로 표현(Represenations)하여 HTTP Method로 행위(Verb)를 정의하여 CRUD 연산을 수행한다.
- 특징
- Uniform (유니폼 인터페이스) HTTP를 사용할 수 있는 환경이라면 플랫폼에 상관없이 사용할 수 있으며 리소스의 타입에 상관 없이 같은 형태의 요청으로 처리됩니다. ⇒ 모바일 , 태블릿 등과 같은 다양한 디바이스 및 이기종(다른 기술언어로 구축)된 시스템에게 HTTP기반 서비스를 제공하기 위해 사용됨.
- Stateless (무상태성) HTTP를 이용하는 만큼 Stateless의 특성을 가집니다. 각각의 요청에 대한 정보를 저장하지 않고 별개의 요청으로 처리합니다. 덕분에 구현이 쉽고 서버의 부담을 덜어줄 수 있습니다.
- Cacheable (캐시 가능) HTTP를 사용하기 때문에 웹의 기본 인프라를 사용할 수 있습니다. 따라서 캐시 기능을 이용해 같은 URI에 대한 반복된 요청을 효율적으로 처리할 수 있습니다.
- Self-descriptiveness (자체적인 표현 구조) JSON, XML 등을 이용하는 메세지 구조로 해당 메세지가 무엇을, 어떤 행위를 의미하는지 직관적으로 이해할 수 있습니다.
- Client - Server 구조 서버는 API 제공, 클라이언트는 유저에 대한 처리를 전담하는 구조를 가지기 때문에 서버와 클라이언트의 역할을 분명하게 구분할 수 있습니다. (클라이언트는 REST API를 통해 서버와 정보를 주고 받는다)
- 계층형 구조(Layered System) 클라이언트는 대상 서버와 직접 통신하는지 아니면 중간 서버와 통신하는지 알 수 없습니다. 따라서 클라이언트와 서버의 통신 사이에 보안이나 로드 밸런싱등을 위한 중간 계층을 추가할 수 있습니다.
- 자원을 이름(URI)으로 구분하여 해당 자원의 상태를 주고받음 즉, 웹에 존재하는 모든 자원에 고유한 URI(통합자원식별자:Uniform Resource Identifier)를 부여해 활용 (uri 는 url 의 상위개념 )
- "서비스별 분리 , 통합"에 대한 표준화된 방법을 제공어플리케이션의 복잡도가 증가 -> 서비스별로 독립적으로 구축, 운영하는 것에 대한 필요성 대두ex) 고객정보서비스 | 예약서비스 | 항공편서비스
- 자원(SW가 관리하는 모든 것)의 표현을 통해 상태를 전달한다
- 기본적으로 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용한다 ⇒ 웹의 장점을 최대한 활용할 수 있다.
- 필요성
- 기존 Service
- 요청에 대한 처리 후, 가공된 데이터를 특정 플랫폼에 적합한 형태의 View로 만들어서 반환
- REST Service
- 데이터만 처리하거나 처리 후 반환될 데이터가 있으면 JSON이나 XML 형식으로 전달하기 때문에 View에 대해서 신경쓸 필요가 없다. ⇒ 멀티플랫폼에 대한 지원이 가능하다. ⇒ 이러한 이유로 OPEN API에서 많이 쓰임
- 기존 Service
- 장점
- HTTP 프로토콜을 그대로 사용하기 때문에 REST API 사용을 위한 별도의 인프라가 필요 없음
- HTTP 표준을 따르는 모든 플랫폼에서 사용이 가능
- REST API 메시지가 의도하는 바를 명확하게 나타내기 때문에 의도하는 바를 쉽게 파악 가능
- 클라이언트와 서버의 역할을 명확하게 분리
- 단점
- 명확한 표준이 존재하지 않음
- HTTP 메소드 형태가 제한적임(GET, POST, PUT, DELETE)
- EX
- 웹 어플리케이션 = 웹 브라우저와 웹 서버가 연결되어 사용자에게 가치를 제공 = 웹 브라우저가 웹 서버에 접속한 것 ( 웹 서버 ≠ 웹 어플리케이션 )
ex) 1. 2명의 사용자가 각각 자신의 웹 브라우저로 같은 웹 서버에 접속한다면 2개의 웹 애플리케이션이 실행되고 있는 것이다.
2. 웹 브라우저로 웹 사이트를 이용하는 예를 들어보자. 사용자가 웹 페이지 A에서 웹 페이지 B로 가는 링크 클릭 시, 웹 브라우저는 링크가 가리키는 B를 렌더링해서 보여줌 링크를 클릭함으로써 브라우저가 보여주던 페이지는 A에서 B로 바뀌었다. 즉, 웹 애플리케이션의 상태가 변경된 것이다. 또한 이 상태의 변경은 representation의 전송(Transfer)을 통해 이루어졌다. 그렇기 때문에 이것이 REpresentational State Transfer인 것.
- CF)
- 모든 payload는 representation HTTP 메시지의 payload로 전달되는 모든 것은 하나의 representation이거나 적어도 그의 일부이다. ex)
- PUT 메서드를 이용해 “welcome” 이란 텍스트를 전송해서 greeting 리소스의 representation을 업데이트하는 경우, 클라이언트가 서버로 전송한 “welcome”은 representation이다.
- 성공시나 에러시의 메시지도 역시 representation
- 업데이트가 성공하여 서버가 “성공적으로 업데이트되었습니다”라는 메시지를 응답의 payload로 돌려보냈다면 이 메시지 역시 representation이다.
- “권한이 없습니다”라는 에러 메시지로 응답했다면 그 메시지도 역시 representation이다.
- Unidentified representation : 그 메시지는 representation이 맞고 어떤 존재하는 리소스에 대한 것이지만 그 리소스를 가리키는 uri가 뭔지는 모르는 것. 이론적으로 정확한 정답은 “Content-Location 헤더에 들어있는 uri가 가리키는 리소스”이지만 보통 Content-Location 헤더는 비어 있을 것이므로 현실적인 정답은 “uri를 모르는 어떤 리소스”이다. (어떤 payload가 unidentified representation인지 판단하는 방법은 RFC 7231의 “3.1.4.1. Identifying a Representation” 에 자세히 나와있다.)
- HTTP를 이용해서 오래 개발을 해 온 개발자라도 representation에 대해 잘 몰랐을 수 있다. 왜냐하면 2014년에 HTTP/1.1이 개정되기 전 까지는 representation의 개념이 명세에 명확하게 드러나 있지 않았기 때문이다. 예를 들어 1999년부터 15년간 HTTP/1.1 명세였던 RFC 2616의 GET 메서드 정의는 다음과 같이 representation에 대한 명시적인 언급이 없었다.
- 오늘날의 HTTP 명세에서 수도 없이 등장하는 개념이기 때문에 이를 모른다면 명세를 올바르게 해석할 수 없다.
- REST의 이해에 representation 이해는 필수다.
- 모든 payload는 representation HTTP 메시지의 payload로 전달되는 모든 것은 하나의 representation이거나 적어도 그의 일부이다. ex)
- 하지만 이제 HTTP를 사용하는 개발자들은 representation에 대해 알아야 하는 이유
3. RestAPI
- API (Application Programming Interface): 프로그램이 상호작용하기 위한 인터페이스
- REST API: REST 기반으로 구현한 서비스 API
- REST API 호출: REST 방식을 따르고 있는 서버에 특정한 요청을 전송하는 것
- REST API 연습용 서비스
- 목킹(Mocking) : 어떠한 기능이 있는 것처럼 흉내내어 구현한 것
- 가상의 REST API 제공 서비스: https://jsonplaceholder.typicode.com
- REST API 호출 실습 예제
- API 호출 경로 : https://jsonplaceholder.typicode.com/users/1 HTTP 메서드: GET
{ "id": 1, "name": "Leanne Graham", "username": "Bret", "email": "Sincere@april.biz", "address": { "street": "Kulas Light", "suite": "Apt. 556", "city": "Gwenborough", "zipcode": "92998-3874", "geo": { "lat": "-37.3159", "lng": "81.1496" } }, "phone": "1-770-736-8031 x56442", "website": "hildegard.org", "company": { "name": "Romaguera-Crona", "catchPhrase": "Multi-layered client-server neural-net", "bs": "harness real-time e-markets" } }
- API 호출 경로: https://jsonplaceholder.typicode.com/users HTTP 메서드: GET
[ { "id": 1, "name": "Leanne Graham", "username": "Bret", "email": "Sincere@april.biz", ... }, { "id": 2, "name": "Ervin Howell", "username": "Antonette", "email": "Shanna@melissa.tv", ... } ... ]
- REST API를 호출하여 회원 정보를 처리하는 예제
- 실행 결과import requests # REST API 경로에 접속하여 응답(Response) 데이터 받아오기 target = "https://jsonplaceholder.typicode.com/users" response = requests.get(url=target) # 응답(Response) 데이터가 JSON 형식이므로 바로 파이썬 객체로 변환 data = response.json() # 모든 사용자(user) 정보를 확인하며 이름 정보만 삽입 name_list = [] for user in data: name_list.append(user['name']) print(name_list)
['Leanne Graham', 'Ervin Howell', 'Clementine Bauch', 'Patricia Lebsack', 'Chelsey Dietrich', '
- API 호출 경로 : https://jsonplaceholder.typicode.com/users/1 HTTP 메서드: GET
4. RESTful
: REST API를 제공하는 웹 서비스을 일컫을 때 말한다.
: REST 원리를 따르는 시스템은 RESTful이란 용어로 지칭됨
- RESTful의 목적이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것 (일관적인 컨벤션)
url에서는 동사 사용x 명사뿐임.
- 컬렉션-복수형을 쓴다. 고유식별자. /movies/inception
HTTP 메소드(get,post,put,delete,update,delete)랑 같이 쓴다. get/mvies
영화의 검색/필터처리를위해 /getTopRateMovies 이런식으로 만들 필요 없음 좋은방식이 아니고 쿼리파라미터 이용하면 돼 /movies?min_rating=9.0 매번 url을 새로 만드는 것보다 개선된방식. pagination도 추가가능함.
api는 통신매개체. 걍 키보드라 생각하면 돼. 누르면 뭔가 작용을 해주는것과 같은 효과 상호작용하기위한 중간매개체 코드끼리 서로 소통하기 위해들어진 것. RestAPI,GraphQL APi..여러가지가 있는데 다른 종류의 api인거지 같은 목적임. 프로그램끼리의 소통 ex-공공api,날씨정보api..해당앱,서버와소통하수있는 ㅁㅐ개체. 데이터,서버를 갖고 있는 사람들이원하는대로 디자인 가능함. 접근권한이 있꺼나 사용제약금액/용량이 제한된 것도 있음. web api : 브라우저를위해 만든 api 크롬,파폭 등등 다 활용할 수 잇는 키보드.. 원랜 api가 작앗는데늘엇나서 이젠 기능이 커짐 내부적으로 어케 작동하는진 밖에선 안보여. 걍 나는 버튼누르면 뒤에서 작동하고 나는 결과만 보는 것.
참고)
https://imjeongwoo.tistory.com/137 https://freedeveloper.tistory.com/280 https://blog.npcode.com/2017/04/03/rest의-representation이란-무엇인가/ https://blog.npcode.com/2017/03/02/바쁜-개발자들을-위한-rest-논문-요약/ https://devdange.tistory.com/entry/Web-REST-API-기초부터-정확히-이해하기
각주
- 아키텍쳐 애플리케이션을 설계, 제작하는데 사용하는 패턴과 기술의 총칭
- Payload(페이로드) 전송되는 데이터. 데이터를 전송할 때, 헤더와 메타 데이터, 에러 체크 비트 등과 같은 다양한 요소들을 함께 보내어 데이터 전송의 효율과 안정성을 높이게 된다. 이 때, 보내고자 하는 데이터 자체를 의미하는 것이 바로 페이로드이다. 운송업에서 비롯한 단어이고 지급(pay)해야 하는 적화물(load)을 의미한다.우리가 택배 배송을 보내고 받을 때, 택배 물건이 페이로드이고, 송장이나 박스, 뽁뽁이와 같은 완충재 등은 부가적인 것이기 때문에 페이로드가 아니다. ex) 유조선 트럭이 20톤의 기름을 운반한다면 트럭의 총 무게는 차체, 운전자 등의 무게 때문에 그것보다 더 될 것이다.이 모든 무게를 운송하는데 비용이 들지만, 고객은 오직 기름의 무게만을 지급(pay)하게 된다. 그래서 ‘pay-load’란 말이 나온 것이다.
- JSON(JavaScript Object Notation) 데이터를 주고받는 데 사용하는 경량의 데이터 형식. 키와 값의 쌍으로 이루어진 데이터 객체를 저장한다. ex)
{ "id": "gildong123", "password": "1!2@3#4$", "age": 30, "hobby": ["football", "programming"] }
Uploaded by Notion2Tistory v1.1.0