REST / REST API / RESTful

REST란

REST(Representational State Transfer)는 월드 와이드 웹과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식이다. Representational State Transfer를 해석해보면 대표적인 상태 전달이란 말이됩니다. 쉽게 풀어서 말하면 자원(resource)의 표현(representation)에 의한 상태전달이라고 많이들 말한다.

자원의 대표

• 자원(Resource) : 넓은 의미로 해당 소프트웨어가 관리하는 모든 것. 문서, 그림, 데이터, 심지어 소프트웨어 자체가 될 수도 있음
• 자원의 표현 : 그 자원을 대표하기 위한 이름을 뜻함. 예를들어, DB의 학생 정보가 자원일 때 ‘students’를 자원의 표현으로 정할 수 있다.

상태 전달

데이터가 요청되어지는 시점에서 자원의 상태를 전달하는 것을 뜻합니다. 일반적으로 JSON, XML 형태로 데이터를 주고 받는다.

종합해보면

결론적으로 자원을 이름으로 구분하고 해당 자원의 상태를 주고 받는 모든것이 REST라고 할 수 있지만, 일반적으로 REST라고 하면 좁은 의미로 HTTP를 통해 CRUD를 실행하는 API를 뜻한다. 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에 웹의 장점을 최대한 활용할 수 있는 장점이 있다.

위 정의에 더하여 REST를 정의하기 위한 6가지 조건이 있다.

• 클라이언트-서버 구조 : 자원이 있는 쪽이 Server, 자원을 요청하는 쪽이 Client가 됩니다. Server는 API를 제공하고 비즈니스 로직 처리 및 저장을 담당합니다. Client는 사용자 인증이나 세션, 로그인 정보 등을 직접 관리하고 책임집니다.

• 무상태(Stateless) : HTTP 프로토콜이 기본적으로 무상태 프로토콜입니다. 즉, 서버는 Client 정보를 기억하지 않습니다. 대신에 클라이언트에서 세션과 쿠키, localStoarge 등을 이용해 정보를 저장해두고 서버에 요청할때 마다 같이 전송합니다.

• 캐시 처리 가능(Cacheable) : HTTP 캐시 사용이 가능합니다. 이부분은 나중에 따로 구체적으로 정리할 필요가 있겠네요.

• 계층화(Layered System) : Client는 Server만 호출한다. Server는 다중 계층을 구성할 수 있습니다. 구체적으로 말하자면, NodeJS에서 Express를 쓰면 미들웨어라는 개념이 있습니다. 이것을 이용해 순수 비즈니스 로직 앞단에 암호화나 사용자 인증 등을 추가할 수 있습니다.

• Code on demand : 옵션입니다. Server로부터 스크립트를 받아서 Client에서 실행합니다.

• 인터페이스 일관성 : URI로 지정한 Resource에 대한 조작을 통일되고 한정적인 인터페이스로 수행하도록 합니다.

REST API란

개념

• API : Application Programming Interface의 약자. 응용 프로그램에서 사용할 수 있도록, 운영 체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스를 뜻한다 (한마디로 말해서 사용설명서라고 볼 수 있다)

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

설계 규칙

• URI로 정보의 자원을 표현한다. 일례로 www.velog.io/ 뒤에 나오는 부분을 의미한다. /write, /read, /login 등 여러가지가 존재할 수 있다. 이런 이름을 정할때 권장하는 방법이 몇가지 있다.
  • 동사보다는 명사를, 대문자보다는 소문자를 사용할 것
  • 단수명사, 복수명사는 상황에 따라서 사용. 예를 들어 /posts/1 => posts들 중에 1번 포스트 호출
• HTTP Method(GET, POST, DELETE, PUT 등)로 자원에 대한 행위를 표현한다.
  • 일례로 GET은 조회라는 의미를 담고 있으므로 GET /posts/show/1 같이 쓰지 말고, GET /posts/1 이라고 쓰면 된다.

그 외에 자잘한 규칙으로는 URI 마지막 문자로 슬래시를 포함하지 말것. 불가피하게 긴 경로는 하이픈(-)을 사용할 것. 밑줄(_)은 사용하지 말것. 대문자 사용은 피할 것 등이 있다.

설계 예시

역시 예시를 보면서 이해하는게 좋다.

CURD란 Create, Update, Read, Delete를 나타내는 유명한 용어이다. 이것들은 HTTP Method와도 연결이 되고, DB Query와도 연결이 되는 부분이다.

GET, POST, DELETE는 알겠는데 HTTP에서 수정관련해서는 메소드가 2개가 존재한다. PUT과 PATCH 이 둘의 차이는 뭘까? 🤔

• PUT : 데이터를 새 정보로 통째로 교체할 때 사용
• PATCH : 데이터의 특정 필드를 수정할 때 사용

게시글 포스트 API

구체적인 예시가 있으면 이해하기 더 좋을것이다. 여기서는 많이들 쓰는 게시글 포스트관련 API를 설계해보도록 하겠다.

참고로 앞은 HTTP 메소드이며 뒤에는 경로이다.

• [GET] /posts : 포스트 목록 조회
• [GET] /posts/:id : 특정 포스트 조회
• [POST] /posts : 포스트 작성
• [DELETE] /posts/:id : 특정 포스트 삭제
• [PATCH] /posts/:id : 특정 포스트 업데이트(특정 필드 수정). PUT을 쓰면 새 정보로 통째로 교체. 사용방식에 따라 선택
• [GET] /posts/:id/comments : 특정 포스트에서 댓글 조회
• [POST] /posts/:id/comments : 특정 포스트에서 댓글 등록
• [DELETE] /posts/:id/comments/:commentID : 특정 포스트의 특정 댓글 삭제
• [PATCH] /posts/:id/comments/:commentID : 특정 포스트의 특정 댓글 삭제

RESTful이란?

• RESTful이란 일반적으로 REST라는 아키텍처를 구현하는 웹 서비스를 나타내기 위해 사용되는 용어이다.
• REST API를 제공하는 웹 서비스를 RESTful하다고 할 수 있다.
• RESTful은 REST를 REST답게 쓰기 위한 방법으로, 누군가가 공식적으로 발표한 것이 아니다.

장점

그렇다면 이렇게 사용했을때 얻는 장점은 무엇일까?

• 일단 통일성이 있다. 개발팀과 개발팀사이에 혼란도 줄여줄 수 있다.
• API 확장성이 좋다. 같은 URI라고 해도 HTTP Method 방식에 따라서 다르게 사용할 수 있기 때문이다.

단점

GraphQL에서도 REST와 비교를 했던거 같은데 REST API로 개발을 하다보면 엔드포인트가 기본 수십개이다. 그리고 정해진 형식으로 입력받고 전달받을수 밖에 없다. 이것을 수정하려고 하면 고칠 것이 꽤나 많아질 것이다.

그래서 나온게 GraphQL인데 나중에 공부해보는 것도 추천한다.

마침

처음에 REST도 모르고 /createPost, /selectPost 같이 API를 구성했던 적이 있었다. 나중에는 싹다 갈아엎었지만...😡😡 웹개발 관련해서는 모를 수 없는 개념이기 때문에 개발하기 전에 꼭 이것부터 숙지하는게 좋을 것이다.

API 관리는 중요하다. 오죽하면 Swagger와 같은 API관리 도구도 존재하고, 혹은 따로 API 문서를 파일로 작성하기도 한다.

References

• A MEAN Blog : https://www.a-mean-blog.com/ko/blog/%ED%86%A0%EB%A7%89%EA%B8%80/_/REST%EC%99%80-RESTful-API
• [Network] REST란? REST API란? RESTful이란? : https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html