'일관성 있는 웹 서비스 인터페이스 설계를 위한 REST API 디자인 규칙'을 읽고

e-book으로 소개되고 있다.

 

Rest API 디자인에 대해서 간결하고 깔끔하게 정리되어 있는 책이다.

 

Representational State Transfer의 약자로 로이필딩의 박사 논문 주제로 세상에 소개 되었고 알려져있다. 

 

HTTP 통신을 위한 API 설계의 아키텍처 중 하나이다.

 

웹 개발자로 일하기 위해서는 REST API라는 말을 정말 많이 들어볼 것이다. 실상 그 속속까지 아는 사람은 많지 않다.

 

어디선가 아무곳에서나 REST API를 이야기하니 로이 필딩이 Http base의 인터페이스들을 모두 REST API라고 부르는 것에 좌절감을 느낀다든가(~이렇게 짜야 REST API라고 할 수 있어!라는 포스팅을 함), REST라는 단어에 대해 논쟁을 많이 한다는 이야기를 본 기억이 있다.

 

그래서 평화를 위해 그냥 Web API라는 용어를 사용하는게 낫다~ 라는 개발 커뮤니티의 댓글들을 본 적도 있다.

 

각설하고, 이 책은 REST API를 작성할 수 있는 규칙을 소개해주고 있다.

 

Http status code도 나열식으로 어떨 때 이 코드를 써야한다~라는 식도 있어서 나중에 개발할 때 어떤 status 코드를 보내줘야할지 써먹어야겠다는 생각을 했다.

 

Http method에 대한 설명도 있는데, 기본적으로 알고 있는 지식이겠지만 한 번 더 짚고 넘어갈 수 있다. 심화적인 부분도 담겨있어 유용하다. 예를 들면, '특정한 액션에 대한 요청은 POST를 써야한다'가 있었다. POST는 Resource를 생성, 저장할 때 사용한다 정도만 알고 있었다. 

 

회사에서 맡고 있는 서비스 특성 상, 다양한 회사와 API 통신을 해야하는데 이 책에 설명대로라면 Http Method 사용방식을 제대로 지키지 않는 회사들이 많다.

 

모든 리소스를 가져오든, 수정하든, 요청하든 POST로 일괄사용하는 경우도 있고 아니면 GET 또는 POST로 모든 API가 작성되어있다. 물론 나도 반성 중....

 

그리고 HAETOAS! 아마 여기서 REST 방식으로 API 개발에 좌절하지 않을까 싶은데.. 실무에서 한 번도 적용해본적 없고.. 이해하기 어려웠다. (솔직히 마지막 장으로 갈수록 이해가 어려워 쓱 읽기만 했다)

 

자기가 있는 리소스 위치를 알려줘야한다든가, self-descriptive해야한다든가.. 라는 말들이 있었지만 앞으로도 매번 찾아보다보면 자연스럽게 이해할 날이 오겠지.

 

REST API에 학습으로 그런 REST API로 괜찮은가 이 영상을 많이 보았을 것인데, 이 영상을 보고 지금 이 책을 보면 시너지 효과를 볼 수 있다.