REST API와 Metadata

  REST API에서 자원(Resource)은 client에게 표현할 수 있는 수단이다. 이 자원을 표현할 수 있는 설계가 잘못된다면 REST API에 이점도 사라진다. 그만큼 설계도 어렵다는 뜻이다. 자원을 이야기하며 빼놓을 수 없는 게 바로 Metadata라고 생각한다. wiki에서는 Metadata를 이렇게 말한다.

데이터의 데이터. 어떤 목적을 가지고 만들어진 데이터.

  데이터의 데이터라는 뜻은 무엇일까? 사진을 예로 들어보자. 스마트폰을 이용해서 사진을 찍으면 그 사진에 대한 파일이 생성된다. 그 파일의 크기(용량), 생성날짜와 시간(사진을 찍은 날짜와 시간), pixel, 등 여러 가지 그 사진 파일을 표현할 수 있는 데이터가 있을 것이다. 바로 이것이 사진의 Metadata라고 할 수 있다. 그리고 목적을 갖는 데이터다. 그 목적은 여러 가지가 있겠지만.

  다시 REST 이야기로 넘어와서 REST에서 자원을 이야기하면서 Metadata를 이야기한 이유는 바로 자원을 표현할 수 있는 URI가 client(Rest API를 사용하는 입장)에서는 Metadata라고 볼 수 있기 때문이다. REST API를 잘 설계하기 위해서는 자원을 표현할 수 있는 URI를 잘 설계해야 하는데, 이게 만만치 않다. 사실 URI 설계 그냥 하면 되는 거 아니야? 라고 생각할 수 있지만 그렇지 않다. URI는 곧 REST API로 만들어지는 도메인을 어떻게 명확하게 표현하느냐인데, 도메인 이해하는 것도 어려운데 그 도메인을 명확하게 표현하는 게 쉬울까?

REST API는 자원과 행위로 표현을 한다.

예를 들면

• GET /members
• GET /members/1
• POST /members
• PUT /members/1
• DELETE /members/1

  member(회원)에 대한 CRUD URI이다. 쉽게 설계할 수 있고 이해하기도 쉽다. 하지만 위는 예제일 뿐이다. 실제 우리가 만드는 소프트웨어의 도메인은 훨씬 더 이해하기 어렵고 변화가 자주 일어난다. (복잡한 예제를 만드는 것 조차 끔찍하다.)

  하지만 client 입장에서 다시 한번 생각해보자. client는 잘 설계된 REST API를 이용해 생성된 데이터의 자원으로 URI를 만들어 낼 것이다. var url = "/members/" + member.id 이런 식으로 말이다.
  하지만 생성된 데이터를 이용해 REST API 만드는 우리가 URI도 만들어서 같이 표현해 주면 되지 않을까? var = member.self 처럼 사용할 수 있게.

  Metadata 이야기를 좀 더 해보자. 사진을 예로 들었는데 그것보다 개발에 관한 이야기로 예를 들어보자.
우리는 개발하면서 많은 Metadata를 만들어내고 있다. 스프링을 처음 사용하기 위한 첫 번째 난관이 무엇인가? 바로 설정이다. @Bean 애노테이션이라는 놈을 이용해서 들어보지도 못한 빈이라는 객체를 만들어낸다. 심지어 XML로 설정을 했을 당시에는 더 복잡했던거 같다. (적어도 내가 처음 스프링 처음 시작할때는 설정이 제일 어려웠다.) 지금은 Spring Boot라는 좋은 놈이 있지만, 그것도 사실 사용하다보면 설정을 하기 위해 지식과 경험이 필요하다.

  그렇다면 우리는 왜 이렇게 어려운 설정을 해야할까? 바로 스프링에게 우리는 이렇게 사용할꺼야! 라는 Metadata를 주는것이다. 사실 Java에서 리플렉션이라는 기술 자체도 Java에서 정의되는 모든 것 Class, Method, Field, Annotation, 등.. 을 Metadata를 알아내서 무언가를 할 수 있는 기술인데, 스프링도 마찬가지로 무언가를 할 수 있게끔 우리가 Metadata를 제공해야한다. 물론 스프링이 시키는대로 우리는 작성해야 하지만 말이다.

결론은 우리는 수많은 Metadata를 만들어내고 있고, 이 Metadata 다시 한번 생각해봐야한다.