[도전 기술!] REST API

안녕하세요? 주니하랑 입니다.

본 내용은 주니하랑이 Web 개발 프로젝트를 하면서 도전했던 기술들에 대한 내용을 정리하는 곳 입니다!

이 글은 함께 프로젝트 했던 Back End 꿈나무 Crew가 작성한 것이에요.

주니하랑도 Back End 개발을 맡았었답니다!

이번 우도독 (우리도 독서!) 프로젝트에서는 RESTful한 API를 설계하기 위해 그런 API로 괜찮은가

( https://www.youtube.com/watch?v=RP_f5dMoHFc )라는 세미나 영상을 보며 REST의 출현 계기와 REST에서 정의한 제약 조건들을 알아보았고, 이러한 제약 조건을 지켜 API를 설계하려고 노력했습니다.

 

 

---

 

 

 

📝 RESTful한 API를 설계하고자 한 이유 ?

분산 하이퍼미디어 시스템을 위한 아키텍처 스타일인 REST를 구성하는 스타일은 다음과 같습니다.

1. Client-Serve
2. Stateless
3. Cache
4. Uniform Interface
5. Layered System
6. Code-on-Demand (optional)

HTTP 프로토콜만 잘 따라도 대부분의 다른 스타일들을 다 지킬 수 있기 때문에 문제가 없지만, Uniform Interface은 대부분 잘 지켜지지 않고 있으며 이 스타일이 지켜지지 않는다면 RESTful한 API라고 할 수 없습니다. REST가 목적하는 바는 독립적인 진화 *이고, 이를 달성하기 위해서는 Unifrom Interface가 필수적입니다.

독립적 진화 * - 서버와 클라이언트가 각각 독립적으로 진화한다. - 서버의 기능이 변경되어도 클라이언트를 업데이트할 필요가 없다.

그러나 사실 우리가 REST API라고 부르는 거의 모든 것들은 제약 조건을 잘 지키지 못하고 있다고 합니다. 그래서 이번 프로젝트에서는 Uniform Interface 중에서도 대부분 잘 지켜지지 않고 있는 제약 조건 중 하나인 Hypermedia as the engine of application state(HATEOAS)을 지켜 REST API를 설계하고자 했습니다.

 

 

💪🏻RESTful한 API 설계를 위한 노력

애플리케이션의 상태는 Hyperlink를 이용해 전이되어야 한다는 것이 HATEOAS 제약 조건입니다. Hyperlink에 자원의 위치(reference)와 자원의 관계(relation)를 명시해줌으로써 클라이언트가 별도의 사전 정보 없이도 이 링크를 이용해 다른 자원에 접근할 수 있기 때문에 서버와 클라이언트의 독립적 진화가 가능하게 합니다.

스프링에서는 이를 위해 Spring HATEOAS라는 프로젝트를 제공합니다.

Spring HATEOAS에서는 Link라는 클래스로 다른 자원에 접근할 수 있는 링크 하이퍼미디어를 제공합니다. 이를 활용하여 자원을 표현하려면 RepresentationModel 클래스를 상속하는 EntityModel 템플릿 클래스를 사용할 수 있습니다.

RepresentationModel 클래스는 Link 객체를 담을 수 있고 EntityModel 클래스에서는 해당 링크를 가진 자원 객체를 담을 수 있는데 Spring HATEOAS에서는 이 EntityModel을 이용하여 응답에 사용할 객체를 캡슐화하고 링크 객체를 등록하여 클라이언트에게 현재 접근할 수 있는 자원을 명시하는 RESTful 한 응답을 쉽게 생성할 수 있습니다.

 

그런데 EntityModel을 이용하여 응답에 사용할 객체를 캡슐화하는 과정을 매번 일일이 코드로 작성해야 할까요?

이렇게 동일한 코드가 반복된다면 이를 별도의 함수나 클래스로 빼내는 것도 생각해보아야 합니다. 그래서 저희는 이번 프로젝트에서 Spring HATEOAS에서 제공하는 RepressentationModelAssembler 인터페이스를 활용해보았습니다.

이 인터페이스는 toModel, toCollectionModel 메서드만 정의하고 있습니다. 말 그대로 매개변수로 받은 객체를 RepresentationModel로 변환하는 역할이고, 앞서 사용했던 EntityModel이 이 RepresentationModel을 상속받고 있기 때문에 다음처럼 사용할 수 있습니다.

 

 

 

 

 

👏🏻 결론

REST API에 대해서 많이 들어보긴 했지만 정작 REST API가 무엇인지, RESTful하게 API를 설계하면 뭐가 좋은지에 대해서는 모르고 있었습니다. 이번 기회에 REST의 출현 계기와 몇가지 제약 조건들을 공부해보면서 그냥 API를 작성하는 것보다 지켜야 할 것도 많고, 조금은 더 복잡하게 느껴짐에도 불구하고 REST API를 설계하는 이유를 조금은 짐작해볼 수 있었습니다.

REST는 수십년에 달하는 긴 시간에 걸쳐 진화하는 웹 어플리케이션을 위한 것입니다. 당장 코드를 짤 때에는 이렇게 하는 것이 시간이 더 오래 걸리고, 어렵다고 느껴질 수는 있지만 장기간 서비스하는 웹 어플리케이션을 개발한다면 웹 브라우저, HTTP, HTML과 독립적이기 때문에 이것들이 변경된다고 해도 따로 코드를 변경할 필요가 없이 독립적 진화가 가능하도록 하는 REST를 따르는 것이 더 좋다고 생각 됩니다.

이렇게 REST를 따르는 것의 장단점을 잘 고려하여 REST를 따를 것인지는 구현하려는 서비스의 목적에 맞춰 판단하여 합리적으로 결정하는 것이 중요할 것 같다고 느꼈습니다.

 

---

 

주니하랑의 글이 마음에 드셨나요? 구독과 공감! 그리고, 댓글은 주니하랑에게 많은 힘이 됩니다