RestFul API 개념: 자원(Resource), 행위(Method), 표현(Message)

RestFul API

- Representational State Transfer

- 서버나 서비스에 존재하는 모든 자원(이미지, 동영상, DB자원)에 고유한 URI를 부여해 활용하는 것 = 자원에 대한 주소를 지정하는 방법론을 의미

(빨간색 표시해놓은 부분만 기억하자)

- API의 형식을 URL의 형식으로 표현해놓은 것.

- 여러가지 API가 있지만, 필자는 RestFul API를 사용해보도록 하겠다.

 

- 좌측은 프론트엔드, 우측은 백엔드, 가운데가 API

- 백엔드는 서버를 개발한다. API 서버를 개발한다.

- API는 프로그램을 만들수 있는 기능이다. API라는 것은, 개념적으로 규칙을 중간에 만들어놓은 것. 로그인의 기능을 구현하고 싶으면, URL 주소를 어떻게 전달해달라, 그러면 서버가 데이터 정보를 전달해 줄것이다. 로그아웃을 하고 싶으면, URL 주소를 어떻게 전달해달라, 그러면 서버가 처리하고, 처리되면 이렇게 줄것이다.라는 규칙이다.

- 서로를 통신하기 위한 규칙을 만들어놓는다 =  API를 설계한다고 한다. 규칙을 만들어놓으면, 그 규칙을 보고 서버/프론트앤드 개발자는 동시에 각자 개발할 수 있다. 

 

(서버에서 개발 끝나야, 프론트앤드에서 개발할 수 있는데요? 이러면 안된다.)

 

통신을 위한 REST 구성

- 자원(Resource): http://service.com/users 라는 형태의 URI

- 행위(Method): GET/POST/DELETE/PUT과 같은 메소드

- 표현(Message): JSON, XML 등의 형태를 이용해 표현

HTTP POST, http://service.com/users {     “users”:   {         “name”:   “sol”      } }

 

- REST란: 상기 기재해놓은 부분은 만족하면 REST라고 한다.

(무조건 외우자, 중요)

- REST API 개발을 하려면 위 세가지 조건이 만족해야 개발할수가 있다. 

 

- 우리가 프로젝트를 수행할 때, 가장 먼저 하는 일이 자료조사, 그 다음이 화면기획서이다.

화면 기획서란, 로그인/메인화면, 메인화면에서 나오는 또 다른 화면, 사진 업로드 하는 화면, 사진 업로드 완료되면 나타나는 화면, 내 정보화면 등 많은 화면을 표시해주는 기획서이다.

  되게 간단한 서비스도 10개 이상의 화면은 있다. 

- 화면 기획서가 다 완성되면, 화면 기획서를 기반으로 API 설계를 한다. API 설계가 되면 프론트엔드, 백엔드 서로 나눠서 작업한다.

- 백엔드 같은 경우에는 우선적으로 데이터 베이스 설계를 한다 = 테이블을 만든다. 그 후에 코드를 작성한다. 

 

- 요청과 응답이 있다. 

- 요청은 항상 클라이언트가 먼저 한다. 응답은 항상 서버가 한다. 

ㄴ 요청 같은 경우, 회원가입: 사용자가 아이디, 비번을 입력을 하면, 클라가 서버에게 요청한다. 이 사람 회원가입 좀 시켜줘. 그 요청할 때 필요한 것이 URL(Resource)과 데이터 (이메일/비번). 해당 데이터를 서버로 보내서, 서버에서는 그 데이터를 DB에 저장한다(= 회원가입).

ㄴ 앱을 실행했더니, 최신 동영상이 나온다. 유저가 앱을 실행하면 유튜브 리스트 중에서 최신 리스트 가져와달라고, 클라는 요청을 한다. 서버는 요청을 받으면, 최신 DB에서 저장되어있는 데이터를 가져와서 클라에게 제공해준다. 

ㄴ 이러한 행위들을 GET/POST/DELETE/PUT(Method) 이라고 한다.

 

- 메시지(Message)란, 전달하는 데이터를 어떤 형식으로 보내는지. Json, XML등의 형식이 있다. 데이터를 네트워크를 통해서 주고받을 때는 형식이 있어야한다. 

 

HTTP POST, http://service.com/users {     “users”:   {         “name”:   “sol”      } }

- 위의 형식을 Json이라고 한다. Json은 Java Script Object Notation

- 유저의 정보를 서버에 전달하고 싶고, 유저의 이름은 sol이다. 

- 파이썬으로 치면, 리스트와 딕셔너리의 조합으로 데이터를 표시했다는 뜻

 

- XML은 예전 방식이고, 사람이 볼 때 가독성이 더 떨어지고, 데이터보다는 태그가 더 많이 들어가서, 데이터상으로만 볼 때 낭비가 상당하다. 이건 요새 잘 사용하지 않는다.

 

URI(URL) 구성 명칭

- 전체적인 주소가 URL, port + path + query string을 URI라고 한다. 

- port 뒤에는 항상/(슬래시)가 나온다.

- /(슬래시)는 경로라는 뜻이다.

- path뒤에 ?(물음표)는 쿼리 스트링인데, 상기 이미지 같은 경우는 id는 HTML이고, page는 12라는 뜻이다. 정보를 또 전달하려고 하면 그 뒤에 &를 붙이고 작성하면 된다. 

 

HTTP Methods와 Message Format

HTTP Methods

- 주요 메소드 5가지

GET	For reading data	리소스 조회, 오직 데이터를 받기만 한다.
POST	For creating data	요청 데이터 처리, 주로 데이터 등록에 사용
PUT	For updating data by completely replacing data with new content	리소스를 수정, 해당 리소스가 없으면 생성
PATCH	For updating data, but by partially modifying a few attributes	리소스를 일부만 변경
DELETE	For deleting data	리소스 삭제

 

GET: 보통 리소스를 조회할 때 사용하며, 서버에 전달하고 싶은 데이터는 query를 통해서 전달한다. 메시지 바디를 사용해서 데이터를 전달할 수는 있지만, 지원하지 않는 곳이 많다.

POST: 데이터 요청을 처리하고, 메시지 바디를 통해서 서버로 데이터를 전달한다. 주로 신규 리소스를 등록하거나 프로세스 처리에 사용된다.

PUT: 리소스가 있으면 대체하고, 리소스가 없으면 생성한다. 쉽게 말해 데이터를 덮어쓴다.

PATCH: PUT과 마찬가지로, 리소스를 수정할 때 사용하지만, PATCH는 리소스를 일부분만 변경할 수 있다.

DELETE: 리소스를 제거할 때 사용한다.

Message Format: Json 문법

 

Arrays are enclosed by []	배열은 [ ]로 이루어져있다.
Objects can be represented by {}	객체는 { }로 표현한다
Name/values always exist in pairs, and are delimited by “:”	이름/값은 항상 쌍으로 있으며 “ : ”로 구분된다.
strings are enclosed by “”	문자열은 “ ” 로 이루어져 있다.

 

-  Json은 무조건 큰 따옴표로 표시한다. (작은 따옴표 안됨)