REST API

공부한 것

• REST API

간단 정리

• REST는 자원, 행위, 표현의 세 가지로 이루어져 있다.
• REST가 가진 몇 가지 특징이 있다.
  • 유니폼 인터페이스: URI로 지정된 리소스에 대한 조작을, 통일되고 한정적인 인터페이스로 수행하는 아키텍처 타입.
  • 무상태성: 작업을 위한 상태 정보를 따로 저장하지 않는다. 단순히 들어온 요청을 처리하면 될 뿐!
  • 캐시 가능: HTTP가 가진 캐싱 기능을 적용할 수 있다. (Last-Modified, E-Tag 등을 사용)
  • 자체 표현 구조: REST API 메시지만 보고도 알아들을 수 있다.
  • 클라이언트-서버 구조: REST 서버는 API를 제공하고, 클라이언트는 사용자 인증이나 Context 등을 직접 관리하는 구조. 한 마디로, 역할이 명확히 구분되어 있다. 해서 서로 간 뭘 개발해야 할지 명확해지고, 의존성이 줄어들게 된다.
  • 계층형 구조: REST 서버는 다중 계층을 둘 수 있다! 암호화 계층 등의 추가를 통한 구조상의 유연성이나, 프록시 및 게이트웨이 같은 네트워크 기반 중간매체를 사용할 수 있다.
• URI는 정보의 자원을 표현해야 하며, 자원에 대한 행위는 HTTP Method로 표현해야 한다.
  • URI상의 리소스명이 가급적 명사로 되어 있어야 하는 이유. 동사는 HTTP Method면 족하다!
• POST, GET, PUT, DELETE로 CRUD를 구현할 수 있다.
• URI를 설계할 때는.. 일단 슬래시(/)가 계층을 나타낼 때 쓰이며 주소 끝에 붙이면 안 된다는 것과, 가급적 리소스 이름에 대문자를 쓰지 않아야 한다는 것을 주의하자.

고민한 점 및 생각해본 점

• HTTP에 대해 활동학습을 통해 배우면서, 앱 개발자로써 알아야 할 REST API에 대해 생각해보았다!
  • 이를 위해 평소 즐겨 보던 아티클의 내용을 정리해 보았다.
• 먼저 REST가 뭐냐? 라고 한다면, REpresentational State Transfer이다. 대표? 상태? 전송?
• 왜 REST가 HTTP를 하면서 생각이 났냐면, 이 REST 자체가 HTTP의 우수성과 시너지를 내고자 만들어진 아키텍처이기 때문.
  • HTTP Method를 보고 직관적으로 생각이 났다고 하는 게 좀 더 맞을런지 모르겠다.
• 몇 가지 규칙만 지켜 준다면, 매우 간단하면서도 강력한 도구가 될 것임이 자명해 보인다.
• 자신만의 REST API를 짤 일이 언젠간 있을 것이고, 또 그렇지 않더라도 앱 개발자인 나의 입장에서 REST에 대해서만 잘 알아 두어도 이러한 데이터를 주고받기 위한 모델을 짤 때 좀 더 생각이 트일 것이기 때문에, 잘 알아두는 것이 좋다고 생각된다.
• URL이 URI의 하나라는 것이 재미있었다. URI는 리소스를 식별하기 위한 통합 지원 식별자고, URL은 네트워크 상에서 리소스가 어디 있는지 알려 주는 역할을 하기 때문.
  • 다만, URI는 식별하고 URL은 위치를 가리키는 정도의 차이는 있다!
  • https://mine.gg/index.html 는 서버에서 파일의 위치까지도 가리키므로 URI이자 URL
  • https://mine.gg/index 은 파일의 위치는 가리키지 않지만 해당 페이지의 식별자가 되므로 URI

참조

https://meetup.toast.com/posts/92
https://www.charlezz.com/?p=44767