오로지 Retrofit 라이브러리를 이해하기 위해서 작성되기 시작한 글
1. API
: 두 소프트웨어를 통신가능하게하는 메커니즘
ex. 휴대폰 날씨 앱이 api 통해 기상청시스템과 '대화'하여 최신 날씨 표시함
Application Programming Interface(애플리케이션 프로그램 인터페이스)의 줄임말
인터페이스는 두 애플리케이션 간의 서비스 계약.
이 계약은 요청/응답으로 두 애플리케이션이 통신하는 방법을 정의함
1-1. API는 어떻게 작동하나요?
API 아키텍처는 일반적으로 클라이언트와 서버 측면에서 설명된다.
아키텍처란? : 서비스의 동작원리
(최적화를 목표로 두고 시스템 구성과 동작원리
그리고 시스템의 구성환경 등을 설명 및 설계하는 청사진 또는 설계도입니다.)
출처: https://linsaeng.tistory.com/m/35
1-2.
클라이언트: 요청 보내는 애플리케이션
서버: 응답 보내는 애플리케이션
ex. 서버: 기상청 날씨데이터
클라이언트: 모바일 날씨 앱
1-3. API가 생성된 시기와 이유에 따라 API는 네 가지 방식으로 작동함
-SOAP API
: 과거에 더 많이 사용되었고 유연성 떨어짐
-RPC API
-Websocket API
: JSON 객체를 사용하여 데이터를 전달하는 또 다른 최신 웹 API 개발이다.
클라이언트 앱과 서버 간의 양방향 통신을 지원한다. 서버가 연결된 클라이언트에 콜백 메시지를 전송할 수 있어 REST API보다 효율적이다.
-REST API
: 오늘날 웹에서 볼 수 있는 가장 많이 사용되고 유연한 API이다.
1️⃣클라이언트가 서버에 요청을 데이터로 전송한다.
2️⃣서버가 이 클라이언트 입력을 사용하여 내부 함수를 시작하고,
3️⃣출력 데이터를 다시 클라이언트에 반환한다.
1-4. API의 다른 유형은 무엇인가요?
API는 아키텍처와 사용 범위에 따라 분류된다. API 아키텍처의 주요 유형은 이미 살펴보았으므로 사용 범위를 살펴보자.
- 프라이빗 API: 기업 내부에 있으며 비즈니스 내에서 시스템과 데이터를 연결하는 데만 사용됩니다.
- 퍼블릭 API: 일반에 공개되며 누구나 사용할 수 있습니다. 이러한 유형의 API와 관련된 권한 부여와 비용이 있을 수도 있고 없을 수도 있습니다.
- 파트너 API: 이는 B2B 파트너십을 지원하기 위해 권한이 부여된 외부 개발자만 액세스할 수 있습니다.
- 복합 API: 두 개 이상의 서로 다른 API를 결합하여 복잡한 시스템 요구 사항이나 동작을 처리합니다.
즉, API의 핵심은 애플리케이션을 서로 연결하여 통신할 수 있게 한다는 것이다.
그중에서도 REST API 에 대해 더 자세히 알아보자
2. REST API
2-1. REST란?
REST는 Representational State Transfer라는 용어의 약자로서 2000년도에 로이 필딩 (Roy Fielding)의 박사학위 논문에서 최초로 소개되었습니다. 로이 필딩은 HTTP의 주요 저자 중 한 사람으로 그 당시 웹(HTTP) 설계의 우수성에 비해 제대로 사용되지 못하는 모습에 안타까워하며 웹의 장점을 최대한 활용할 수 있는 아키텍처로써 REST를 발표했다고 합니다.
REST: Representational State Transfer의 줄임말로, 클라이언트가 서버 데이터에 액세스하는 데 사용할 수 있는 GET, PUT, DELETE 등의 함수 집합을 정의한다.
클라이언트와 서버는 HTTP를 사용하여 데이터를 교환한다.
http에 대해 잠깐 짚고 넘어가자.
*/
HTTP란?
(HyperText Transfer Protocol)
텍스트 기반의 통신 규약으로 인터넷에서 데이터를 주고받을 수 있는 프로토콜(통신 규약과 동의어).
이렇게 규약을 정해두었기 때문에 모든 프로그램이 이 규약에 맞춰 개발해서 서로 정보를 교환할 수 있게 되었다.
클라이언트(사용자)가 요청하면 서버가 그에맞게 응답 하는 형태이다.
Plain text로 부터 JSON 데이터 및 XML과 같은 형태의 정보도 주고 받을 수 있다.
Request(요청): 클라이언트가 서버에게 연락하는 것.
-Request Method (요청의 종류)
- GET : 자료를 요청할 때 사용
- POST : 자료의 생성을 요청할 때 사용
- PUT : 자료의 수정을 요청할 때 사용
- DELETE : 자료의 삭제를 요청할 때 사용
-Request 구성
1. 시작줄(첫 줄)
2. 헤더(두 번째 줄부터터)
3. 본문(헤더에서 한 줄 띄고)
Response(응답): 서버가 요청에 대한 답변을 클라이언트에게 보내는 것
-Response의 Status Code(상태 코드)
굉장히 많은 종류가 있고 숫자 세자리로 이루어져 있으며, 크게 다섯부류로 나뉜다.
- 1XX (조건부 응답) : 요청을 받았으며 작업을 계속한다.
- 2XX (성공) : 클라이언트가 요청한 동작을 수신하여 이해했고 승낙했으며 성공적으로 처리했음을 가리킨다.
- 3XX (리다이렉션 완료) : 클라이언트는 요청을 마치기 위해 추가 동작을 취해야 한다.
- *리다이렉션이란? 클라이언트가 서버에 url A를 요청했을 때, 서버가 http 응답 메시지를 통해 "url B로 다시 요청해봐~"라고 클라이어언트에게 다른 url(길, 방향 등)을 지시할 수 있는 것. ex. 웹툰 결제할 때 로그인 창으로 리다이렉트 시킴
- 4XX (요청 오류) : 클라이언트에 오류가 있음을 나타낸다.
- 5XX (서버 오류) : 서버가 유효한 요청을 명백하게 수행하지 못했음을 나타낸다.
-Response 구성
1. 시작줄(첫 줄)
2. 헤더(두 번째 줄부터)
3. 본문(헤더 뒤부터)
/*
여기까지 http에 대한 설명이었다. 다시 rest api로 돌아와서...
2. REST API
2-1. REST란?
REST는 Representational State Transfer(표현 상태 전송으로 이해)라는 용어의 약자로서 2000년도에 로이 필딩 (Roy Fielding)의 박사학위 논문에서 최초로 소개되었습니다. 로이 필딩은 HTTP의 주요 저자 중 한 사람으로 그 당시 웹(HTTP) 설계의 우수성에 비해 제대로 사용되지 못하는 모습에 안타까워하며 웹의 장점을 최대한 활용할 수 있는 아키텍처로써 REST를 발표했다고 합니다.
복습)아키텍처: 시스템이 어떻게 동작하는지에 대한 설계도
웹을 활용하는 '아키텍처'로써 REST를 발표했으므로,
REST는 개발자가 웹(HTTP)을 잘 이용하도록 하는 설계도 겸 지침서이다.
REST는 클라이언트가 서버 데이터에 액세스하는 데 사용할 수 있는 GET, PUT, DELETE 등의 함수 집합을 정의한다.
클라이언트와 서버는 HTTP를 사용하여 데이터를 교환한다.(http는 요약하자면 통신규약)
2-2. REST의 구성
- 자원(Resource) - URI
- 클라이언트는 URI를 이용해 자원을 지정하고 해당 자원의 상태(정보)에 대한 조작을 서버에 요청함.
- 행위(Verb) - HTTP Method
- HTTP 프로토콜은 GET, POST, PUT, PATCH, DELETE의 Method를 제공한다.
- 표현(Representations)
- 클라이언트와 서버가 데이터를 주고받는 형태에는 JSON, XML, TEXT, RSS 등이 있다.(JSON, XML이 일반적)
2-2-1. URI vs URL 뭐가 다를까?
URL(Uniform resource Locator) - 흔히 웹 주소라고도 하며, 컴퓨터 네트워크 상에서 리소스가 어디 있는지 알려주기 위한 규약. URI의 서브셋(부분집합)이다.
URI(Uniform resource Identifier) - 특정 리소스를 식별하는 통합 자원 식별자. 웹 기술에서 사용하는 논리적 또는 물리적 리소스를 식별하는 고유한 문자열 시퀀스.
이해가 되지 않을 수 있다.
URL은 URI에 포함된다. 가장 큰 차이점은 다음과 같다.
URI는 식별하고, URL은 위치를 가리킨다.
예를들어 내 이름이 "김철수"면 이건 식별자(identifier)다. 이는 uri 와 비슷하지만 내 위치나 연락처에 대한 정보가 없으므로 url은 될 수 없다.
"경기도 성남시 분당구 불정로 6"는 주소다. 주소는 특정 위치를 가리킨다. url 및 uri와 비슷하며 간접적으로(?) 내가 있는 장소로 식별한다.
실제 네트워크상에서 URI와 URL의 예시는 다음과 같다.
첫번째 주소는 웹서버의 실제 파일 위치를 나타내는 주소이므로 URI이면서 URL이다.
두번째 주소는 실제로 index라는 파일이 웹서버에 존재하지 않으므로 URL은 아니다. 하지만 서버 내부에서 이를 처리하여 결국 index.html을 가리키기 때문에 URI라고 볼 수 있다.
2-3. REST 특징(내가!!!!! 이해한)
1) Uniform(유니폼 인터페이스) - 리소스에 대한 조작 방식이 통일되어있다
2) Stateless(무상태성) - 상태를 저장하지 않아서 서버는 요청만 처리하고 불필요한 정보를 관리하지 않는다.
3) Cacheable(캐시 가능) - http라는 기존 웹표준을 그대로 사용해서 http의 캐싱 기능을 사용할 수 있다.
4) Self-descriptiveness(자체 표현 구조) - REST API 메시지만 보고도 이를 쉽게 이해할 수 있는 구조이다.
5) Client - Server 구조 - 서버와 클라이언트의 역할이 명확하게 구분되어 있어 서로간 의존성이 적다.
6) 계층형 구조 - 다중 계층으로 구조가 유연해질 수 있다.
(참조: https://prodo-developer.tistory.com/129 [RESTful API에 대해 알아보자])
*CRUD Operation(소프트웨어 개발 내에서 데이터 관리 및 조작에서 수행되는 네 가지 필수 작업)
-Create : 생성(POST)
-Read : 조회(GET)
-Update : 수정(PUT)
-Delete : 삭제(DELETE)
-HEAD: header 정보 조회(HEAD)
2-4. RESTful API
REST의 기본 원칙을 지킨 서비스 디자인을 흔히 "RESTful하다."라고 표현한다.
(REST는 어떤 구현체가 아니라, 아키텍처 스타일이라는 것을 기억하자.)
REST API 설계 시 가장 중요한 항목은 다음의 2가지로 요약할 수 있다.
첫 번째, URI는 정보의 자원을 표현해야 한다.
두 번째, 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE)로 표현한다.
(REST API 디자인 예시에 대한 참조: https://prodo-developer.tistory.com/129)
2-5. RESTful API vs REST API
-REST API는 REST의 특징을 기반으로 서비스 API를 구현한 것을 의미한다.
-최근 Open API(누구나 사용할 수 있도록 공개된 API) 등을 제공하는 기업 대부분은 REST API를 제공한다.
-REST API의 가장 큰 특징은 각 요청이 어떤 동작이나 정보를 위한 것인지를 그 요청의 모습 자체로 추론이 가능하다는 것이다.
-RESTful은 REST의 설계 규칙을 잘 지켜서 설계된 API를 일컫는다.
2-6. 그냥 알아두면 좋은것
-REST는 HTTP만을 위해 만들어진 것이 아니다. (HTTP 문제점을 해결하기 위해 만들어지긴 했지만) '아키텍처'일 뿐이므로 특정 네트워크 프로토콜에 국한되지 않는다.
-REST와 RESTful은 같은 말이 아니다. RESTful은 공식적인 단어가 아니다.
-REST API는 HTTP 메서드를 사용한다는 말은 사실 틀렸다. 다시한번 강조하자면 REST는 특정 네트워크 프로토콜에 국한되지 않는다.
(위에 적은 개념과 충돌한다.)
*참조:https://2dongdong.tistory.com/76
REST API를 간단히 요약하자면
URI는 정보의 자원만 표현해야 하며, 자원의 행위는 HTTP Method에 명시한다는 것이다.
3. Retrofit(사실상 Retrofit 2, Retrofit은 deprecated됨)
Retrofit는 서버와 클라이언트 간 http 통신을 위한 인터페이스입니다.
복습)
http는 인터넷에서 데이터를 주고받을 수 있는 통신규약으로서,
클라이언트(사용자)가 요청하면 서버가 그에맞게 응답 하는 형태이다.
Retroift은 REST API 방식을 사용합니다.
즉, REST는 아키텍처(=가이드, 규칙, 지침서)로서, HTTP 통신을 설계할 때 지켜야 한다.
Retrofit 라이브러리는 http 통신을 할 때, REST 방식을 따른 REST API를 쉽게 구현할 수 있도록 하는 라이브러리이다.
참조:
rest api: https://aws.amazon.com/ko/what-is/api/
rest api: https://todaycode.tistory.com/2
rest api: https://prodo-developer.tistory.com/129
http:
https://velog.io/@surim014/HTTP란-무엇인가
http 리다이렉트: https://webstone.tistory.com/65
url vs uri: https://www.charlezz.com/?p=44767
RESTful API vs REST API
https://dev-coco.tistory.com/97
rest api 에 대한 오해
https://2dongdong.tistory.com/76
'KUIT-앱 개발 프로젝트 동아리' 카테고리의 다른 글
9주차 실습(2)-Retrofit 로직 구현 (2) | 2023.11.25 |
---|---|
9주차 실습(1)- Retrofit 사용 준비 (2) | 2023.11.21 |
8주차 실습(1)-카카오맵 가져와서 따라하기 (0) | 2023.11.17 |
5주차 복습 메모 (1) | 2023.11.14 |
7주차실습(3)-room db&코루틴 응용 (0) | 2023.11.10 |