Rest Api

이번에는 Rest Api에 대해 글을 써보려고 합니다. 백앤드 개발자를 준비하게 되면서 REST Api라는 말을 많이 듣긴 했지만 여태까지는 REST Api에 대해 제대로 이해를 하지 못했고 수박 겉핡기 식의 이해를 가지고 개발을 진행했던 것 같아서 이번 시간을 계기로 확실하게 이해를 해보려고 합니다.

Rest Api는 Rest와 api가 합쳐진 용어로 인데 각각의 용어부터 간단하게 정리해보겠습니다.

Rest란?

Rest는 "Representational State Transfer"의 약자로 자원을 이름으로 구분하여 대한 자원의 상태(정보)를 주고받는 것을 의미합니다. 여기서 자원은 해당 소프트웨어가 관리하는 모든 것입니다. 예를 들면 게시판을 만든다고 하면 게시글과 댓글 혹은 사용자가 각각이 자원이라고 볼 수 있습니다. 또한 자원의 상태를 주고받는 다는 것은 데이터가 요청되어지는 시점에서 자원의 상태(정보)를 주고받는 것을 의미하며 주로 json을 통해 데이터를 주고받습니다.

이와 같은 의미는 알겠는데 왜 개발자들은 Rest를 입에 달면서 말하는 이유는 무엇일까요? Rest는 기본적으로 웹의 기존 기술과 Http프로토콜을 이용해서 데이터를 주고받는 것입니다. 즉, Rest는 http의 큰 특징인 서버 클라이언트에서 구조에서 통신 방식의 하나라고 보면 좋을 것 같습니다.

다시 Rest의 구체적인 개념을 살펴보면 Http Uri를 통해 자원을 명시하고, http Method를 통해 해당 자원에 대한 CRUD(Create Read Update Delete)를 적용하는 것을 의미합니다. 조금 더 쉽게 정리하면 Rest는 자원을 중심으로 Http Method를 통해 자원을 처리하도록 설계된 아키텍쳐입니다.

Http Method란?

http Method란 클라이언트가 웹 서버에게 사용자 요청의 목적이나 종류를 알리는 수단

	종류	의미
1	Post	요청 데이터 처리, 주로 데이터 등록에 사용
2	Get	리소스 조회
3	Put/Patch	리소스를 수정시 사용
4	Delete	리소스 삭제

Rest 구성요소

1. 자원(Resource) : URI
   모든 자원에는 자신을 식별해주는 고유한 ID(primary key)가 있고, 이 자원들은 서버에 존재합니다. 사용자는 Http에서 URI(Uniform Resource Identifier)를 통해 자원을 지정하고 자원의 상태(정보)에 대한 가공을 서버에 요청합니다.
2. 행위(Verb) : Http Method
   클라이언트가 URI를 통해 서버로 요청을 보내면 서버는 Http 프로토콜의 Method를 사용해서 자원을 가공합니다.
3. 표현(Representation of Resource)
   서버는 앞서 말한 것과 같이 클라이언트 요청에 맞는 Http 프로토콜의 Method를 활용해 자원을 가공하고 이를 클라이언트에게 적절한 응답을 보내는데 이때 Json,Xml,Test,Rss 등의 형태로 자원을 제공합니다.

Rest의 장점

• Http 프로토콜의 인프라를 그대로 사용하여 REST API 사용을 위한 별도의 인프라를 구축할 필요가 없다.
• Http 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하다.
• 외부의 사용자나 다른 개발자들이 봐도 Rest 메시지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악할 수 있습니다.
• 여러가지 서비스 디자인에서 생길 수 있는 문제를 최소화한다.
• 서버와 클라이언트의 역할을 명확하게 분리한다.

Rest의 단점

• 표준이 존재하지 않아 정의가 필요하다.
• 사용할 수 있는 메소드가 4가지밖에 없다.
• HTTP Method 형태가 제한적이다.

이와 같이 Rest에 대해 알아보았습니다. 이를 정리하면서 제가 이해한 Rest는 Http통신의 특징을 활용해 이용해 자원을 가공하는 것입니다. 이제는 api에 대해서 알아보겠습니다.

api란?

api는 Application Programming Interface의 줄임말로 Application은 고유한 기능을 가진 모든 소프트웨어를 의미하며 Interface는 두 Application 간의 서비스 계약을 의미합니다. 즉 api는 소프트웨어끼리의 통신 과정에 있어서 약속된 문서라고 보면 좋을것 같습니다.

이와 같이 api에 대해 알아보았지만 쉽게 와닿지 않습니다. 정리하는 저 역시도 그래서 이게 뭔데? 라는 느낌이 강했었구요. 그래서 api를 설명할 때 주로 비유를 많이 활용하는데 비유를 통해 간단하게 설명해보겠습니다. 우리는 우편을 보낼 때 우편송장을 활용합니다. 먼저 우편송장을 보겠습니다.

우편송장에 비유해서 간단하게 api를 설명하면 보내는 이(클라이언트)는 우편송장에 맞게 정보를 입력해 줍니다. 보내는 이의 성명, 전화, 주소와 받는이의 성명, 전화 ,주소 그리고 배송정보를 체크하면 우체국 택배(서버)는 이에 맞게 배송을 진행해 줍니다. 즉 우편 송장은 보내는 이와 우체국 택배 사이의 의사소통을 위한 형식(문서)이라고 보면 좋을 것 같습니다. 다시 이를 통해 api를 보면 api는 한 애플리케이션에서 형식에 맞게 요청을 보내면 그에 기대하는 정보나 기능을 수행하도록 정리된 형식이라고 보면 쉽게 이해가 될 것 같습니다.

이제 다시 Rest Api에 대해 알아보겠습니다.

Rest Api란?

위에서 각각 이해한 Rest와 api의 개념을 합치면 Rest api는 자원을 URI에 명시하여 http 프로토콜의 가반 Method를 활용해 두 애플리케이션이 상호작용할 수 있도록 약속된 형식이 정의할 수 있습니다.

이와 같이 Rest Api의 정의에 대해 알아보았습니다. 선행 개발자들이 Rest api를 조금더 직관적으로 파악할 수 있게 세운 설계 기본 규칙에 대해서 간단하게 알아보겠습니다.

Rest Api 설계 기본 규칙

1. URI는 정보의 자원을 표현해야 한다는 것입니다.
   자원은 동사보다는 명사로 표현해야하며 대문자보다는 소문자로 표현해야합니다.
   또한 자원의 도큐먼큐먼트(객체 인스턴스나 데이터베이스 레코드와 유사한 개념) 이름은 단수 명사를 사용하는 것이 좋으며 서버에서 관리하는 디렉터리 이름과 클라이언트에서 관리하는 리소스 저장소에서는 복수명사를 사용해야합니다.
2. 자원에 대한 가공은 Http Method로 표현해야합니다.
   앞서 설명한 http Method를 활용해 자원을 가공하되 URI에는 이와 같은 행동이 드러나서는 안됩니다.
3. 슬래시 구분자는 계층 관계를 나타내는데 사용합니다.
4. URI 마지막 문자로 슬래시(/)를 포함하지 않습니다.
5. 밑줄(_) 대신 하이픈(-)을 활용해 URI의 가독성을 높여줍니다.
6. 파일 확장자는 URI에 포함하지 않습니다.
7. 자원 간에 연간관계가 있는 경우 에는 리소스명/리소스ID/관계가 있는 다른 리소스 명으로 표기합니다.

Resst Api 설계 예시(게시글과 댓글)

CRUD	HTTP verbs	Route
게시글들의 목록 표시	GET	/posts
특정 하나의 게시글 내용 표시	GET	/posts/id
게시글를 생성	POST	/posts
특정 게시글을 수정	PUT	/posts/id
특정 게시글 삭제	DELETE	/posts/id
특정 게시글 내 댓글 표시	GET	/posts/id/comments

Reference

https://www.incodom.kr/REST
https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html