RESTful API란?
세 줄 요약.
1. 최근 많은 서비스들의 client-side는 웹 하나로 정형화 되어있지 않고 다양한 웹 브라우저 환경과 모바일 환경에서 사용된다.
2. 각 client환경에 맞추어서 서버프로그램을 여러개 개발하는 것은 무리이므로 하나로 뭉치자 -> RESTful API의 등장!
3. REST의 원칙을 잘 지켜서 작성한 API가 RESTful API이다.
REST의 등장배경
최근의 많은 서비스들은 다양한 웹 브라우저, 다양한 모바일 환경 (IOS, Android) 에서 사용되고 있다. 예전의 서버 프로그램은 단순히 하나의 브라우저에서 동작했다. 그러나 현재의 서버 프로그램은 다양한 환경에서의 통신에 대응해야 한다. 그래서 등장한게! REST라는 개념이다.
우리가 자주 사용하는 이 티스토리를 크롬에서도 사용하고 IE, Firefox, 안드로이드, IOS 에서 사용한다고 치자. RESTful API가 없다면? 각각의 환경에 맞추어서 서버 프로그램을 작성해야한다.
또한 결국 같은 서비스를 이용하는 것이기 때문에 (댓글을 단다든가, 게시글을 작성한다든가..) 작성한 데이터의 동기화도 필요하다. 이 수많은 환경에서 통신하며 어떻게 동기화 할것인가?? 또한 한 서버 프로그램에서 로직이 변경된다면 모든 서버프로그램의 코드를 바꾸어주어야한다.. 상상만해도 탈주하고싶다.
즉 각각의 웹 브라우저, 모바일별로 서버를 만드는 것이 아니라 하나의 서버에서 모든 환경의 클라이언트의 요청을 처리할 수 있게 만들어준다.
RESTful에 대해서 이해한다면 당신은 프로그램 환경에 따라 별도의 서버프로그램을 구축할 필요 없이 하나만 구축하면된다. 좋다. 소스코드도 한번만 고치면된다.
그럼 이제 한번 정의로 들어가보자. 대체 이 REST란 무엇인지?
REST란?
- 분산시스템 설계를 위한 소프트웨어 아키텍처의 하나이다.
- 웹에 존재하는 모든 자원들 (이미지, 동영상, 텍스트, 데이터베이스자원)에 고유한 URI를 부여하여 클라이언트가 잘 이해하고 사용할 수 있게 만들자!
즉, 서버에서 생성하는 (조금 더 정확히 말하자면 웹 상의) 자원을 정의하고, 자원에 대한 주소 및 행위를 정하는 방법론.
REST의 구성 요소
외우자 자행표! 자행표! 자행표! 자행표! 자행표!
(먼저 외워두면 이해가 빨리된다.)
1. Resource(자원)
- 모든 자원은 URI 방식으로 표현한다.
- 모든 자원에는 고유한 ID가 존재하고, 이 자원은 서버에 존재한다.
- 클라이언트는 URI를 이용해 서버에게 자원을 요청한다.
- 예) /order/order_id/1
- 대충 보고 해석해 보자면 order_id가 1인 order에 대한 정보를 달라는 뜻으로 보인다!
2. 행위(Verb)
- 자원의 요청은 모두 HTTP프로토콜의 method를 사용한다.
- HTTP프로토콜 Method의 종류: GET, POST, PUT, DELETE
3. 표현(Representation of Resource)
- 자, 그럼 서버는 클라이언트가 요청한 웹 상의 자원을 어떤 형식으로 넘겨줘야 할까?
- REST에서 하나의 자원은 JSON, XML, TEXT, RSS등 여러 형태의 Representation(표현)으로 나타내어 진다.
즉, 정리하자면 클라이언트가 서버의 정보를 받아올 때! 어떻게 받아오느냐? 클라이언트는 하이고 서버 선생님 저는 order_id가 1인 order에 대한 정보를 받아오고 싶습니다~ 하고 URI형식으로 요청한다. 근데 이 때 요청은! HTTP 프로토콜의 method를 이용하여 받아온다. 여기서는 단순히 정보를 받아오므로 GET method를 사용한다고 하자. 그럼 서버는 order_id가 1인 order에 대한 정보를 DB에서 가져오든, 어디서 가져오든 가져왔을 것이다. 그럼 이 정보를 클라이언트에게 어떻게 제공(표현)하나? JSON, XML등의 형식으로 전달해 주는 것이다!
RESTful API 설계규칙
자, 그럼 이 RESTful API를 수백, 수만명의 개발자가 사용하고 소통하려면 일종의 규칙이 있어야한다. 내맘대로 만들다가는 첩첩산중 엄청난 큰일이 난다. 물론 장점도 있다. 그 프로그램의 소스코드는 나만 이해할 수 있으니 평생직장 획득가능 ㅋㅋ;ㅈㅅㅈㅅ
그럼 RESTful API 설계 규칙에 대하여 알아보자.
특징은 크게 두가지로 나뉜다.
1. URI는 정보의 자원을 표현해야한다.
- resource는 동사보다는 명사를, 대문자보다는 소문자를 사용한다.
Ex) GET /eat/apple -> GET /food/apple
- resource의 도큐먼트 이름으로는 단수 명사를 사용해야 한다.
- resource의 컬렉션 이름으로는 복수 명사를 사용해야 한다.
- resource의 스토어 이름으로는 복수 명사를 사용해야 한다.
Ex) GET /Member/1 -> GET /members/1
2. 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE 등)으로 표현한다.
- URI에 HTTP Method가 들어가면 안된다.
Ex) GET /members/delete/1 -> DELETE /members/1
- URI에 행위에 대한 동사 표현이 들어가면 안된다. (즉, CRUD 기능을 나타내는 것은 URI에 사용하지 않는다.)
Ex) GET /members/show/1 -> GET /members/1
(이미 HTTP method가 GET 보여달라는 뜻인데 show를 붙일 필요는 없다.)
Ex) GET /members/insert/2 -> POST /members/2
- 경로 부분 중 변하는 부분은 유일한 값으로 대체한다.(즉, :id는 하나의 특정 resource를 나타내는 고유값이다.)
Ex) student를 생성하는 route: POST /students
Ex) id=12인 student를 삭제하는 route: DELETE /students/12
+URI 설계시 지켜야 할 사항들
1. 슬래시 구분자(/)는 계층 관계를 나타내는데 사용
2. URI 마지막 문자로 슬래시(/)를 포함하지 않는다.
3. 하이픈(-)은 URI 가독성을 높이는데 사용
4. 밑줄(_)은 URI에 사용하지 않는다.
5. URI 경로에는 소문자가 적합하다.
6. 파일확장자는 URI에 포함하지 않는다.
부록
그래서 RESTful API는 필요한가?
필요하다. 그렇다.
지금은 봐주고 봐줘서 사람들은 주로 서비스를 이용할때 웹 아니면 모바일 환경에서 사용한다. 근데 스마트TV, 스마트워치, AR, VR, 홀로그램 기술이 발전되고, 발전한 기술이 대중화 된다면? 지금은 스마트워치는 만보기용도로 사용한다지만, 진짜 스마트워치로 블로그 글을 수저할 수 있지도 않는가? 그럼 또 스마트워치전용 서버프로그램을만들고,,, 만들다보면 RESTful API를 사용하고 싶어질 것입니다.
ref.
https://velog.io/@somday/RESTful-API-%EC%9D%B4%EB%9E%80
https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html