[웹개발] REST API(2)

REST API의 규칙

REST에서 가장 중요하며 기본적인 규칙은 다음과 같다.

• URI는 정보의 자원을 표현해야 한다.
• 자원에 대한 행위는 HTTP 메서드(GET, POST, PUT, DELETE 등)로 표현한다.

 

이어서 REST API URI 규칙을 살펴보자.

 

소문자를 사용한다.

• 대문자는 문제를 일으키는 경우가 있기 때문에 소문자를 사용한다.
• RFC3986은 체계 및 호스트 구성 요소를 제외하고 URI는 대소문자를 구분하여 정의한다.

 

언더바(_) 대신 하이픈(-)을 사용한다.

• 가독성을 위해 긴 Path를 표현하는 단어는 하이픈으로 구분한다.
• 폰트에 따라서 언더바 문자는 안 보일 수 있다.

 

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

• 마지막 슬래시는 전혀 의미가 없다.
• URI에 포함되는 모든 글자는 리소스의 유일한 식별자로 사용되어야 한다.
• URI가 다르면 리소스가 다르다는 것이다.
• 역으로 리소스가 다르면 URI도 달라져야 한다.

 

계층 관계를 나타낼 때는 슬래시를 사용해야 한다.

• 슬래시는 URI의 경로 부분에서 자원 간의 계층적 관계를 나타내기 위해 사용한다.

 

행위는 포함하지 않는다.

• 행위는 URL 대신 메서드를 사용하여 전달한다.

 

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

• Content-Type이라는 헤더를 통해 전달되는 대로 미디어 타입을 사용하여 body의 콘텐츠를 처리하는 방법을 결정한다.
• REST API 클라이언트는 HTTP에서 제공하는 형식 선택 메커니즘인 Accept 요청 헤더를 활용하도록 권장해야 한다.

 

URI에 작성되는 영어를 복수형으로 작성한다.

• 문법에는 안 맞을 수 있지만, 실무에서 많이 사용되고 있다.

 

 

REST의 설계 목표

상호연동성 확보

• 두 개 이상의 컴포넌트들을 결합함으로써, 작업을 더 효율적으로 수행하도록 한다.
• REST는 HTTP와 URI 기반인데, HTTP와 URI 모두 표준이며, 직관적이고 사용이 간단하며 어디서든 동일하게 작동하는 것을 보장할 수 있다.

 

범용 인터페이스

• REST를 위한 표준(HTTP, URI)으로 어디서든지 사용 가능한 범용 인터페이스를 제공한다.
• 개발자는 비즈니스 로직만 고려하면 된다.

 

컴포넌트의 독립적인 배포

• 컴포넌트의 독립적인 배포는 다른 컴포넌트와 독립적으로 개발을 할 수 있다는 것을 의미한다.
• 규격에 맞추어 개발이 되었다면 다른 컴포넌트가 추가되어도 연동에 무리가 없다.

 

컴포넌트를 중계하는 역할

• 클라이언트는 엔드 서버에 직접 연결할 필요 없이 서비스를 이용할 수 있다.
• REST 서버가 클라이언트와 엔드 서버 중간에서 중계 역할을 한다.
• 로드 밸런싱, 공유 메모리 등을 이용해서 확장성, 성능을 향상할 수 있으며 보안 정책을 적용하기도 용이하다.

출처 : https://velog.io/@somday/RESTful-API-%EC%9D%B4%EB%9E%80

---

Reference

• RESTful API 이란
• REST API URI 규칙