[CS] REST? REST API? RESTful?

REST란?

REST(Representational State Transfer)

• 자원의 이름으로 구분하여 해당 자원의 상태를 주고받는 것
• 어떤 자원에 대해 CRUD(Create, Read, Update, Delete) 연산을 수행하기 위해 URI(Resource)로 요청을 보내는 것

1. HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시
2. HTTP Method(POST, GET, PUT, DELETE, PATCH 등)를 통해
3. 해당 자원(URI)에 대한 CRUD Operation을 적용

💡CRUD Operation
1. Create: 생성(POST)
2. Read: 조회(GET)
3. Update: 수정(PUT)
4. Delete: 삭제(DELETE)

1. REST API 설계 예시

CRUD	HTTP verbs	Route
resource들의 목록 표시	GET	/resource
resource들의 하나의 내용을 표시	GET	/resource/:Id
resource 생성	POST	/resource
resource 수정	PUT	/resource/:Id
resource 삭제	DELETE	/resource/:Id

2. REST 구성 요소 

1. 자원(resource) : HTTP URL
2. 자원에 대한 행위 : HTTP Method
3. 자원에 대한 행위의 내용 (Representations) : HTTP Message Pay Load

Resource
서버는 Unique한 ID를 가지는 Resource를 가지고 있으며, 클라이언트는 이러한 Resource에 요청을 보냅니다. 이러한 Resource는 URI에 해당합니다.

Method
서버에 요청을 보내기 위한 방식으로 GET, POST, PUT, PATCH, DELETE가 있습니다. CRUD 연산 중에서 처리를 위한 연산에 맞는 Method를 사용하여 서버에 요청을 보내야 합니다.(GET과 POST의 차이는 여기를 참고해 주세요!)

Representation of Resource
클라이언트와 서버가 데이터를 주고받는 형태로 json, xml, text, rss 등이 있습니다. 최근에는 Key, Value를 활용하는 json을 주로 사용합니다.

💡 URL vs URI
URI (Uniform Resource Identifier, 통합자원식별자)
- 인터넷에 있는 자원을 나타내는 유일한 주소.
- 인터넷에 존재하는 각종 정보들의 유일한 이름이나 위치를 표시하는 식별자
ex : https://velog.io
https - 웹에서 주로 HTTP프로토콜을 사용
velog.io : host 도메인 IP
​
URL (Uniform Resource Locator)
- 웹주소, 컴퓨터 네트워크 상에서 리소스가 어디 있는지 알려주기 위한 규약
​
​
URI는 식별하고, URL은 위치 ( URI > URL )

3. REST의 장단점

장점

1. HTTP 프로토콜의 인프라를 그대로 사용하므로 REST API 사용을 위한 별도의 인프라를 구축할 필요가 없음
2. HTTP 프로토콜의 표준을 최대한 활용하여 여러 추가적인 장점을 함께 가져갈 수 있게 해 줌
3. HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능함
4. REST API 메시지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악할 수 있음
5. 서버와 클라이언트 역할을 명확하게 분리 - 서버만 별도의 작업으로도 사용이 가능함
6. 별도의 개발이 가능

단점

1. 표준이 존재하지 않음
2. 사용할 수 있는 메서드가 4가지 (HTTP Method)뿐
3. 구형 브라우저에서 아직 제대로 지원해 주지 못하는 부분이 존재
4. PUT, DELETE를 사용하지 못하는 점

​

REST API란?

REST API (Representational State Transfer API)

REST의 원리를 따르는 API를 의미

1. REST API의 설계 기본 규칙

• URI는 자원의 정보를 표시
  • resource는 동사보다 명사로, 대문자보다는 소문자 사용

GET /Product/1  -> GET /product/1

• 자원에 대한 행위는 HTTP Method ( GET, PUT, POST, DELETE)로 표현
  • URI에 HTTML Method가 들어가면 안 된다.

GET /product/delete/1 -> DELETE /product/1

• URI에 행위에 대한 동사 표현이 들어가면 안된다(CRUD 기능을 나타내는 것은 URI에 사용하지 않는다.)

GET /product/show/1 -> GET /product/1 
GET /product/insert/2 -> POST /product/2

•  경로 부분 중 변하는 부분은 유일한 값으로 대체한다(즉 :id는 하나의 특정 resource를 나타내는 고유값이다)

2. REST API 설계 시 주의점

• 슬래시 구분자(/)는 계층 관계를 나타내는데 사용한다.

http://localhost:8080/product/option

• URI 마지막 문자로 슬래시를 포함하지 않는다

http://localhost:8080/product/(x)

• 하이픈(-) 은 URI 가독성을 높이는 데 사용
• 밑줄(_)은 사용하지 않는다.
• URI 경로에는 소문자가 적합
• 파일 확장자는 URI에 포함하지 않는다.

http://localhost:8080/product/image.jpg(x)

• REST 리소스 간에는 연관 관계가 있는 경우

/리소스명/리소스 ID/관계가 있는 다른 리소스명

ex) GET : /users/{userid}/devices (일반적으로 소유 ‘has’의 관계를 표현할 때)

 

 

REST ful 이란?

HTTP 통신에서 어떤 자원에 대한 CRUD 요청을 Resource와 Method로 표현하여 특정한 형태로 전달하는 방식

• ESTful 이란 REST의 원리를 따르는 시스템을 의미
• REST를 사용했다 하여 모두가 RESTful 한 것은 아님

REST API의 설계 규칙을 올바르게 지킨 시스템을 RESTful 하다 말할 수 있음​

모든 CRUD 기능을 POST로 처리하는 API 혹은 URI 규칙을 올바르게 지키지 않은 API는 REST API의 설계 규칙을 올바르게 지키지 못한 시스템은 REST API를 사용하였지만 RESTful 하지 못한 시스템이라고 할 수 있습니다.

​

1. RESTful의 목적

• 이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것​

2. RESTful 하지 못한 경우

• Ex1) CRUD 기능을 모두 POST로만 처리하는 API
• Ex2) route에 resource, id 외의 정보가 들어가는 경우(/students/updateName)