REST API란?

REST API란?

Representational State Transfer API라는 용어의 약자이다.

REST란 "자원을 URI(Uniform Resource Identifier)로 표시하고 해당 자원의 상태(정보)를 HTTP를 이용하여 자원을 주고 받는 것"을 의미한다.

 

따라서 Restfult API는 REST 특징을 지키면서 API를 제공하는 것을 의미한다.

 

Q) URI 과 URL의 차이점은?

URL은 Uniform Resource Locator로 인터넷 상 자원의 위치를 의미합니다. 자원의 위치라는 것은 결국 어떤 파일의 위치를 의미합니다. 반면에 URI는 Uniform Resource Identifier로 인터넷 상의 자원을 식별하기 위한 문자열의 구성으로, URI는 URL을 포함하게 됩니다. 그러므로 URI가 보다 포괄적인 범위라고 할 수 있습니다.

 

왜 REST에 대해 관심을 가지게 되었는가?

• 애플리케이션의 분리 및 통합 (애플리케이션의 복잡도 증가로 애플리케이션을 어떻게 분리하고 통합하느냐가 중요한 이슈가 됨)
• 멀티 플랫폼에 대한 지원을 위해 서비스 자원에 대한 아키텍쳐를 세우고 이용하는 방법을 모색 (다양한 브라우저와 안드로이드 스마트폰, 아이폰과 같은 디바이스에서도 통신을 할 수 있어야 한다)
• OPEN API를 제공 (내가 만든 서비스에서도 OPEN API를 제공하고자 한다)
• 프론트엔드 (Front-End)와 백엔드(Back-End)가 분리되기 시작 (JSON형태로 데이터를 제공하여 프론트영역과 백엔드 영역의 분리를 통하여 View 영역이 포함되지 않는 서버사이드 개발을 진행)

REST의 구체적인 개념

• HTTP URL(Uniform Resource Identifier)을 통해 자원(Resource)을 명시하고, HTTP Method(POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것을 의미한다.
• 즉, REST는 자원 기반의 구조(ROA, Resource Oriented Architecture) 설계의 중심에 Resource가 있고 HTTP Method를 통해 Resource를 처리하도록 설계된 아키텍처를 의미한다.
• 웹 사이트의 이미지, 텍스트, DB 내용 등의 모든 자원에 고유한 ID인 HTTP URL를 부여한다.

CRUD Operation

METHOD	CRUD
POST	Create
GET	Read
UPDATE	Update
DELETE	Delete

 

REST의 특징

1. Uniform Interface(인터페이스 일관성)

• URI로 지정한 Resource에 대한 조직을 통일되고 한정적인 인터페이스로 수행한다.
• HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하다.
• 특정언어나 기술에 종속되지 않는다.

2. Stateless (무상태성)

• HTTP 프로토콜은 Stateless Protocol이므로 REST 역시 무상태성을 가진다.
• Client의 context를 Server에 저장하지 않는다. (즉, 세션과 쿠기와 같은 context 정보를 신경쓰지 않아도 되므로 구현이 단순해진다)
• Server는 각각의 요청을 완전 별개의 것으로 인식하고 처리한다.
  • 각 API 서버는 Client의 요청만을 단순 처리한다.
  • 이전 요청이 다음 요청의 처리에 연관되어서는 안된다.
  • 물론 이전 요청이 DB를 수정하여 DB에 의해 바뀌는 것은 허용한다.
  • Server의 처리 방식에 일관성을 부여하고 부담이 줄어들며, 서비스의 자유도가 높아진다.

3. Cacheable (캐시 가능)

• 웹 표준 HTTP 프로토콜을 그대로 사용하므로 웹에서 사용하는 기존의 인프라를 그대로 활용할 수 있다.
  • 즉, HTTP가 가진 가장 강력한 특징 중 하나인 캐싱 기능을 적용할 수 있다.
  • HTTP 프로토콜 표준에서 사용하는 Last-Modified 태스나 E-Tag를 이용하면 캐싱 구현이 가능하다.
• 대량의 요청을 효율적으로 처리하기 위해 캐시가 요구된다.
• 캐시 사용을 통해 응답시간이 빨리지고 REST Server 트랜잭션이 발생하지 않기 때문에 전체 응답시간, 성능, 서버의 자원 이용률을 향상시킬 수 있다.

4. Layered System(계층화)

• Client는 REST API Server만 호출한다.
• REST Server는 다중 계층으로 구성될 수 있다.
  • API Server는 순수 비즈니스 로직을 수행하고 그 앞단에 보안, 로드밸런싱, 암호화, 사용자 인증 등을 추가하여 구조상의 유연성을 줄 수 있다.
  • 또한 로드밸런싱, 공유 캐시 등을 통해 확장성과 보안성을 향상시킬 수 있다.
• PROXY, 게이트웨어 같은 네트워크 기반의 중간 매체를 사용할 수 있다.
• 클라이언트는 서버와 직접 통신하는지, 중간 서버와 통신하는지 알 수 없다.

5. Client - Server Architecture (서버 - 클라이언트 구조)

• 자원이 있는 쪽이 Server, 자원을 요청하는 쪽이 Client가 된다.
  • REST Server : API를 제공하고 비즈니스 로직 처리 및 저장을 책임진다.
  • Client : 사용자 인증이나 context(세션, 로그인 정보) 등을 직접 관리하고 책임진다.
• 서로간의 의존성이 줄어든다

6. Self-Descriptiveness (자체 표현)

• Rest API는 요청 메시지만 보고도 이를 쉽게 이해할 수 있는 자체 표현 구조로 되어있다.
  • EX)HTTP POST, http://localhost:8080/board{  "board" : {     "title": "제목",     "content": "내용"  }}

REST API 설계 규칙

REST API를 설계시에 중요한 항목은 두가지이다.

1.  URI는 정보의 자원을 표현해야 한다는 점
2.  자원에 대한 행위는 HTTP Method(GET, POST, DELETE, PUT)로 사용해야 한다는 점

위 사항들을 유의하며 REST API를 설계해야할 때 따라야하는 설계 규칙에 대해 알아보자

1. 소문자를 사용한다. 

주소에서 대소문자를 구분하므로, 카멜방식이 아닌 소문자를 사용하여 작성한다.

 

Bad

http://restapi.example.com/users/postComments

Good

http://restapi.example.com/users/post-comments

 

2. 언더바를 대신 하이픈을 사용한다.

가급적 하이픈의 사용도 최소화하며, 정확한 의미나 표현을 위해 단어의 결합이 불가피한 경우에 사용한다.

 

Bad

http://restapi.example.com/users/post_comments

Good

http://restapi.example.com/users/post-comments

 

3. 마지막에 슬래시를 포함하지 않는다.

슬래시는 계층을 구분하는 것으로, 마지막에는 사용하지 않는다.

 

Bad

http://restapi.example.com/users/

Good

http://restapi.example.com/users

 

4. 행위는 포함하지 않는다.

행위는 URL대신 Method를 사용하여 전달한다.(GET, POST, PUT, DELETE 등)

 

Bad

POST http://restapi.example.com/users/1/delete-post/1

Good

DELETE http://restapi.example.com/users/1/posts/1

 

5.파일 확장자는 URI에 포함시키지 않는다.

REST API에서는 메시지 바디 내용의 포맷을 나타내기 위한 파일 확장자를 URI 안에 포함시키지 않습니다. Accept header를 사용하도록 한다.

 

Bad

http://restapi.example.com/users/photo.jpg

Good

GET http://restapi.example.com/users/photo

HTTP/1.1 Host: restapi.example.com Accept: image/jpg

 

6. 가급적 전달하고자하는 자원의 명사를 사용하되, 컨트롤 자원을 의미하는 경우 예외적으로 동사를 허용한다

 

Bad

http://restapi.example.com/posts/duplicating

Good

http://restapi.example.com/posts/duplicate

 

 

 

 

 

 

 

 

 

 

 

 

참고 

• mangkyu.tistory.com/46mangkyu.tistory.com/46
•  velog.io/@stampid/REST-API%EC%99%80-RESTful-API
• gmlwjd9405.github.io/2018/09/21/rest-and-restful.html
• www.slipp.net/wiki/pages/viewpage.action?pageId=12878219
• devuna.tistory.com/79