REST API를 알기 위해서는 당연히 REST의 개념부터 알아야한다.

REST (Representational State Transfer)

• 2000년도에 로이 필딩(Roy Fielding)의 박사학위 논문에서 최초 공개되었다. 로이 필딩은 HTTP의 주요 저자 중 한 사람으로 그 당시 웹(HTTP) 설계의 우수성에 비해 제대로 사용되어지지 못하는 모습에 안타까워 웹의 장점을 최대한 활용할 수 있는 아키텍처로써 REST를 발표했다고 합니다.

• 클라이언트-서버 사이의 통신 중 자원의 이름(표현)으로 구분하여 해당 자원의 상태(정보)를 주고 받는 것을 의미한다.
  --> 여기서 자원이란 해당 SW가 관리하는 모든 것(문서, 그림, 데이터 등을 포함)이며 자원의 이름으로 구분한다는 것은 아래와 같다.
  (Ex) DB의 학생 정보가 자원일 때 'students'를 자원의 표현으로 정한다.

• WWW과 같은 분산 하이퍼미디어 시스템을 위한 SW 개발 아키텍처의 한 형식

  • REST는 웹의 기존 기술과 HTTP 프로토콜을 기본적으로 그대로 활용하기 때문에 웹의 장점을 최대한 활용할 수 있는 아키텍처 스타일이다.
  • REST는 네트워크 상에서 클라이언트-서버 사이의 통신 방식 중 하나

[구성 요소]

• 자원 (Resource) : URI
• 행위 (Verb) : HTTP METHOD (GET, POST, PUT, DELETE)
• 표현 (Representations)

으로 구성됨.
즉, REST는 URI를 통해 자원을 표시하고, HTTP METHOD를 이용하여 자원의 행위를 정해주며 그 결과를 받는 것을 말한다.

REST 구체적인 개념

• HTTP URI를 통해 자원을 명시하고 HTTP METHOD (GET, POST, PUT, DELETE)를 통해 해당 자원에 대한 CRUD를 적용하는 것을 의미한다.

• 웹 사이트의 이미지, 텍스트, DB 내용 등의 모든 자원에 고유한 id인 HTTP URI를 부여한다.

[CRUD - HTTP METHOD]

• Create : POST (생성)
• Read : GET (조회)
• Update : PUT (수정)
• Delete : DELETE (삭제)
• Head : HEAD (헤더 정보 조회)

클라이언트와 서버간의 데이터를 주고 받는 방식이라는 것은 알겠는데 자원을 어떻게 표현해서 어떻게 데이터를 주고 받는지 이해가 잘 안되었다...

저의 방식으로 이해한 내용은 내가 웹 페이지에 접속하여 내 학사정보를 들어갈 때를 클라이언트 요청이라 생각하였다. 밑의 주소는 학사정보를 조회할 수 있는 가상의 주소라고 하였습니다.

http://api.rest.com/school/students/kimdukbae

위 주소를 통해 웹 페이지에 접속을 하여 내 학사정보를 보려고 하면 서버에 'school/students/kimdukbae로 들어가서 데이터 불러와줘' 라고 이해하였다.
이렇게 서버와 클라이언트간 데이터를 주고 받을 때 숫자나 임시의 id가 아닌 명확한 자원의 이름(표현)을 통해 데이터를 주고 받는구나 라고 이해하였습니다. (제가 잘못된 방법으로 이해할 수도 있습니다...)

REST 특징

1. Uniform Interface (유니폼 인터페이스)

HTTP 표준만 따른다면 어떤 언어 혹은 어떤 플랫폼에서 사용하여도 가능한 인터페이스 스타일이다. IOS, Android 플랫폼 등 특정 언어나 플랫폼에 종속되지 않고 사용이 가능한 특징이 있다.

2. Stateless (상태 정보 유지안함)

REST는 상태 정보를 유지X. 서버는 각각의 요청을 완전히 다른 것으로 인식하고 처리를 한다. 이전 요청이 다음 요청 처리에 연관이 되면 안된다.

3. Cacheable (캐시 가능)

HTTP의 기존 웹 표준을 그대로 사용하기 때문에 HTTP가 가진 캐싱 기능을 적용할 수 있다.

4. Self-descriptiveness (자체 표현 구조)

REST API 메세지만 보고도 쉽게 이해할 수 있는 자체 표현 구조로 되어있다.

5. Client - Server

REST 서버는 API를 제공하고 클라이언트는 사용자 인증에 관련된 일들을 직접 관리한다.
자원이 있는 쪽을 Server라고 하고 자원을 요청하는 쪽이 Client가 된다. 서로간의 의존성이 줄어들기 때문에 역할이 확실하게 구분되어 개발해야할 내용들이 명확해지고 효율성이 증가한다.

6. Layerd System (계층화)

클라이언트는 REST API 서버만 호출한다. REST 서버는 다중 계층으로 구성될 수 있으면 로드 밸런싱, 암호화, 사용자 인증 등을 추가하여 구조상의 유연성을 둘 수 있다.

REST API

API 란 데이터와 기능의 집합을 제공하여 컴퓨터 프로그램간 상호작용을 촉진하며, 서로 정보를 교환할 수 있도록 하는 것. 밑의 예제로 API의 의미를 조금이나마 더 이해할 수 있었습니다.

(Ex) 내가 만든 웹 페이지에 실제로 결제가 되도록 하고 싶다.
--> X 실제로 구현하는 방법도 있다. BUT 너무 비효율적이다.
--> O 결제 API를 이용하면 해결 가능!

• REST 기반으로 서비스 API를 구현한 것

• 간단하게 말해서 REST 기반의 규칙들을 지켜서 설계된 API를 REST API 혹은 RESTful API라고 한다.

REST API 설계 규칙

1. URI는 정보의 자원을 표현해야한다.
   자원의 이름은 동사X -> 명사 사용을 지향 (URI는 자원을 표현하는데 중점을 두어야 하므로 행위에 대한 표현이 들어가면 안된다.)

GET /users/987

2. 자원에 대한 행위는 HTTP METHOD (GET, POST, PUT, DELETE) 로 표현한다. URI에 자원의 행위에 대한 표현이 들어가지 않는 대신 HTTP METHOD를 통해 대신한다.

POST /users	-> 유저 생성하기
GET /users/987	-> id가 987인 유저 조회
DELETE /users/987 -> id가 987인 유저 삭제

3. '/'는 계층 관계를 나타나는데 사용한다.

http://api.rest.com/school/students/kimdukbae
http://api.rest.com/school/teachers/kevin

4. URI 마지막에는 '/'를 사용하면 안된다.

http://api.rest.com/school/students/kimdukbae/ -> X
http://api.rest.com/school/students/kimdukbae  -> O

5. '-'(하이푼)은 URI의 가독성을 높이는데 사용한다. 긴 URI를 사용하게 될 경우 '-'으로 가독성을 높인다.

6. '_'(언더바=밑줄)은 URI에 사용하지 않는다. 보기 어렵거나 밑줄로 인해 문자가 가려질 수 있기 때문이다.

7. URI는 소문자가 적합하다. (대문자 지양)
   대소문자에 따라 각자 다른 리소스로 인식하기 때문이다.

8. 파일 확장자는 URI에 포함하지 않는다. REST API에서는 메세지 바디 내용의 포맷을 나타내기 위한 파일 확장자를 URI안에 포함시키지 않는다.

9. 리소스 간의 관계를 표현하는 방법.

GET : /users/{userid}/devices

RESTful API

• 위의 설명처럼 REST 하게 만들어진 API이다. 하지만 누군가 공식적으로 발표한 용어가 아니다. 개발자들이 비공식적으로 의견을 제시한 것이므로 아직까지 명확한 정의가 없다고 한다.
  하지만 RESTful의 목적은 이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것이다.

(Ex)

CRUD	HTTP METHOD	URI
user들 조회	GET	/users/posts
user 1명만 조회	GET	/users/posts/1
user 생성	POST	/users/create
user 수정	PUT	/users-update
user 삭제	DELETE	/users/delete

위 예제는 임시적으로 만든 예제입니다. 이런식으로 RESTful하게 API를 만들 수 있다.

HTTP 상태 코드

https://ko.wikipedia.org/wiki/HTTP_%EC%83%81%ED%83%9C_%EC%BD%94%EB%93%9C

출처 :
https://brainbackdoor.tistory.com/53
https://meetup.toast.com/posts/92
https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html
https://velog.io/@stampid/REST-API%EC%99%80-RESTful-API
https://velog.io/@rhftnqls/REST-API