[Android] 안드로이드 REST API

​

HTTP (Hypertext Transfer Protocol: 하이퍼본문 전송규약)

: 인터넷에서, 웹 서버와 사용자의 인터넷 브라우저 사이에 문서를 전송하기 위해 사용되는 통신 규약을 말한다.

HTML 문서와 이미지, 동영상, 오디오, 텍스트 문서 등을 주고 받는다.

+ 서버에 REST API로 요청을 보낼 때 HTTP 규약에 따라 신호를 전송한다.

​

​

​

---

​

​

​

REST

(Representational State Transfer : 대표적 상태 전달 )

상태 전달: 데이터가 요청되어지는 시점에서 자원의 상태(정보)를 전달하는 것을 뜻한다.

:웹 시스템 (분산된 하이퍼미디어 시스템을 위한 아키텍쳐 스타일)구조, HTTP 프로토콜 장점을 살릴 수 있는 네트워크 기반 아키텍처

REST API -> REST 형식의 API

​

+API 내용 정리

https://blog.naver.com/88yhtserof/222208729830

 

[Android] 안드로이드 API

​API ( application programming interface : 응용 프로그래밍 인터페이스): 운영체제와 응용프로그램 ...

blog.naver.com

​

​

보통 REST는 HTTP 를 통해 CRUDCreate(생성), Read/Retrieve(읽기/인출), update(갱신), Delete/Destroy(삭제/파괴) 를 실행하는 API를 뜻한다.

->REST 의 가장 중요한 특성: 어떤 동작이나 정보를 필요한 것인지 바로 알 수 있다.

​

REST는 HTTP가 가능한 모든 곳에서 사용할 수 있다.

HTTP 프로토콜을 이용하기 때문에 URLroute 를 통해 자원을 특정짓고 HTTP vebs동사 를 통해 할 일(CRUD)을 지정한다. 또한 JSON 또는 XML를 통해 데이터를 주고 받는 것이 일반적이다.

​

​

---

​

​

​

<REST를 정의하기 위한 조건>

​

1. 클라이언트 - 서버 구조

: 자원(resource)이 있는 쪽이 서버, 클라이언트는 그저 제공되는 인터페이스를 통해 접근하여 응답을 받고 서버는 클라이언트의 상태는 신경 쓰지 않고 제공한 인터페이스에 대한 처리만 담당하여 요청이 들어올 때 그에 맞는 응답을 제공하면 된다. 이렇게 역할이 확실하게 구분되면 서로의 개발에 있어서 의존성이 줄어들게 된다.

​

​

​

2. 무상태stateless: 서버는 요청을 독립적으로 인식해야 한다.

​

3. 캐시 처리 가능Cacheable: 대량의 요청을 효율적으로 처리하기 위해 캐시가 요구된다.

​

4. 계층화Layeres System

: 서버는 API 서버에 여러 계층을 추가하여 유연한 구조로 개발될 수 있다. 클라이언트는 이와 상관없이 REST API 서버만 호출한다.

​

5. Code on demand optional

:클라이언트가 리소스에 대한 표현을 응답으로 받은 후 처리하는 Code를 서버가 제공하는 것을 의미한다.

​

6. 인터페이스 일관성

​

​

​

​

---

​

​

​

​

RESTful

REST는 조건 구현방식에 제약을 두지 않기 때문에 구체적인 가이드라인은 없다. 다만 여러 개발자들이 비공식적으로 의견을 제시한 RESTful을 통해 가이드라인이 제시된다.

목표: 이해하기 쉽고 사용하기 쉬운 REST API 작성

​

CRUD	HTTP verbs	Route
resource들의 목록을 표시	GET	https://(도메인)/resource
resource 하나의 내용을 표시	GET	https://(도메인)/resource/:id(표시할 내용의 인덱스)
resource를 생성	POST	https://(도메인)/resource
resource를 수정	PUT	https://(도메인)/resource/:id(수정할 내용의 인덱스)
resource를 삭제	DELETE	https://(도메인)/resource/:id(삭제할 내용의 인덱스)
일부 resource 수정	PATCH	https://(도메인)/resource/id(수정할 내용의 인덱스)

GET

: 가져오기. 링크를 클릭하거나 주소 표시줄에 URL을 입력할 때마다 브라우저가 사용하는 것이다. URL로 식별된 데이터를 클라이언트로 전송하도록 서버에 지시한다. GET의 요청 결과로 서버 측에서 게이터를 수정해서는 안된다. GET은 읽기 전용이다.

​

PUT : 놓기. 클라이언트가 URL에 의해 식별되는 리소스를 업데이트 요청 시 사용한다.

​

POST : 게시. 새 리소스를 생성할 때 사용한다.

​

DELETE : 삭제. 요청 UPL로 식별되는 리소를 삭제 요청 시 사용한다.

​

PATCH: 일부 resource를 수정 요청 시 사용

​

+ POST/ PUT/PATCH에는 BODY라는 주머니가 있어 정보를 GET이나 DELETE 보다 비교적 안전하고 많이 보낼 수 있다.

​

​

RESTful하지 못한 예:

- CRUD기능을 모두 POST로만 처리하는 API

- Route에 resource, id 외 정보가 들어가는 경우

(/students/updateName, student 하나의 이름만 변경하는 API의 경우 PUT students/:id/name이 되어야 합니다.)

​

​

​

​

​

<응답코드>

:HTTP 응답코드는 클라이언트에게 요청결과를 알려준다.

상태 코드	용례
200 OK	요청을 성공적으로 처리함
201 Created	새 리소스 생성 성공. PUT 또는 POST 요청의 성공을 확인하는 데 사용
400 Bad Request	요청 형식이 잘못됨. 특히 데이터가 유효성 검사를 통과하지 목하거나 잘못된 형식이 경우 POST 또는 PUT 요청에서 발생한다.
404 Not Found	요청한 리소스가 없음.

​

​

​

​

---

​

​

​

​

​

[용어 정리]

​

아키텍처(Architecture): 컴퓨터를 기능면에서 본 구성방식, 최적화를 목표로 두고 시스템 구성과 동작원리 그리고 시스템의 구성환경 들을 성명 및 설계하는 설계도

​

하이퍼미디어(hypermedia) : 하이퍼 텍스트의 성질과 멀티 미디어의 성질 모두를 갖는 것으로서 단지 텍스트 뿐만이 아니라 멀티미디어 정보인 텍스트, 음성, 영상도 포함하여 정보를 구성한 것을 말한다.

​

URL: 작업하려는 항목을 식별하는 방법

URL은 자원(resource)를 식별하는데 사용한다.(자원-웹페이지) resource를 고유하게 식별할 수 있도록 URL를 작성해야한다. URL은 애플리케이션이 처리하는 모든 데이터의 지도 역할을 한다.

​

CRUD(Create(생성), Read/Retrieve(읽기/인출), update(갱신), Delete/Destroy(삭제/파괴)

​

​

​

​

​

https://www.youtube.com/watch?v=iOueE9AXDQQ

참고 영상 (추천)

https://m.blog.naver.com/azure0777/221066646741

참고 자료

https://tuhbm.github.io/2019/04/24/architecture/

참고 자료

https://mmlab.snu.ac.kr/~shlee/MMCW/doc1_1.htm

참고 자료

https://duehd88.tistory.com/entry/CRUD%EB%8A%94-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80

참고 자료

https://code.tutsplus.com/tutorials/a-beginners-guide-to-http-and-rest--net-16340

참고 자료

https://code.tutsplus.com/tutorials/a-beginners-guide-to-http-and-rest--net-16340

참고 자료