[ Rest API ] REST 인터페이스의 제약 사항

---

REST 인터페이스의 제약 사항

---

 

리소스 식별

 

• REST 에서 리소스는 서비스에서 리소스를 클라이언트에게 제공할 수 있게 하는 정보를 추상화 한 것이다.
• 본질적으로 리소스는 사용자나 문서, 이미지, 작업 일 수 있다.
• 리소스는 URL 를 통해 고유하게 식별 할 수 있어야 한다.
• 예를 들어 다음과 같은 URL 은 ID 가 1인 작업을 고유하게 식별한다.
  
  • https://api.example.com/v1/tasks/1
  • 해당 URL 에서 보다시피 URL 에 버전 번호인 v1 을 추가한다.
  • 어떤 사람들은 버전 정보를 리소스 URL 에 넣는 것은 나쁜 습관 이라고 생각한다. 그들은 그것을 HTTP  요청 헤더에 추가하는 것을 선호한다.       
  • 다른 사람들은 Restful API 를 만들 때 버전 관리를 사용하는 것 자체가 옳지 않다고 생각한다. 예를 들어 로이 필딩은 Twitter 에서 다음과 같이 언급 했다.                        

"진정한 REST API 를 만드는 이유는 진화 가능성을 얻기 위함이다. 'v1' 은 API 고객에게 RPC/HTTP 를 나타내는 가운데 손가락이다."   

---

 

표현을 통한 리소스 조작

 

• 리소스는 정보의 추상화라고 언급 할 수 있다.
• 그것은 XML, HTML, JSON 과 같은 다른 형식을 가질 수 있는 표현을 통해 설명되는 상태를 가진다.
• 최근에는 JSON 이 가장 인기있는 리소스 표현 형식이다.
• REST 에서는 리소스를 조작하는 것은 표준 HTTP 메소드를 활용해 서버로 표현 형식을 보내는 것이다.
• 가장 일반적인 메소드는 GET, POST, PUT, PATCH, DELETE 이다.

---

 

자기 서술 메세지

 

• 자기 서술 메세지는 수신자가 그것을 이해하는 데 필요한 모든 정보를 포함하는 메세지다.
• 자기 서술이기에 요청은 별도로 처리할 수 있고 클라이언트와 서버 간의 상호작용은 무상태성이 될 수 있다.
• 자체 서술 메세지를 처리하는 서버는 이전 요청을 처리하는 방법을 기억할 필요가 없다.

---

 

 애플리케이션 상태 엔진으로서의 하이퍼미디어

 

• 이 제약 사항은 종종 HATEOAS 또는 하이퍼미디어 제약 ( hypermedia constraint ) 으로 알려져 있다.
• 로이 필딩의 논문에 이 제약 사항에 대한 상세한 설명은 없다.
• 위키 피디아에는 아래와 같이 정의되어 있다.
  
  • 웹 사용자가 웹 사이트의 홈페이지에 액세스 하는 것과 비슷하게 REST 애플리케이션 초기 URL 에 접근하면 REST 클라이언트는 필요한 모든 행동과 리소스를 검색하기 위한 링크를 동적으로 제공하는 서버를 활용할 수 있어야 한다.
  • 접근이 진행되면 해당 서버는 현재 이용 가능한 다른 작업에 대한 하이퍼 링크를 포함하는 텍스트로 응답한다.
  • 클라이언트가 REST 서비스의 구조 또는 동적 정보를 하드 코딩할 필요가 없다.
• 위와 같이 정의되어 있는 제약 사항을 하이퍼텍스트 주도 방식 이라고하며, 로이 필딩에 따르면 'REST API 는 하이퍼 텍스트 주도 방식 이어야 한다.' 그렇지 않다면 API 는 RESTful 할 수 없고, REST API 하다 할 수 없다.
• 이는 HATEOAS 가 유용하거나 실용적인지에 대한 많은 논쟁을 불러 일으켰다.

---

위에 언급한 사항 모두 REST 의 제약 사항이다.

보다시피 REST 는 몇 가지 제약 사항을 정의하는 아키텍처 스타일이다.

 

이는 API 를 어떻게 설계해야 하는지에 대한 표준이 아니며, 구현의 세부 사항을 지정하지 않는다.

RESTful API 를 만드는 데는 선호하는 프로그래밍 언어를 사용하면 된다.

---

글이 도움이 되었다면 좋아요 / 구독 부탁 드립니다 : )

---