RESTful API??

면접을 다녀왔다. "RESTful API가 무엇인지 설명해주세요." 라는 질문을 듣고 어..? "서버와 클라이언트가 HTTP통신으로 데이터를 주고받는 것입니다"라고 답변했다. 사실 답변하고나서 이게 맞나? 음...아키텍쳐 뭐시기 본거같은데 저게 맞나? 나름 잘 알고있다 생각했는데 전혀 아니어서 신선한 충격이었다.(아키텍처는 애플리케이션 개발에 사용되는 패턴이나 기술의 총칭)
학교에서 프로젝트를 진행하면 서버와 통신할때 Retrofit라이브러리를 쓰면서 서버파트 팀원과 RESTful을 구축했는데 대충 이런거다 정도로만 알고있었지 깊게 정확히 무엇인지 찾아본 기억이 없다..분명 내가 구축하고있는데 정확이 모른다는게 참 아이러니하다. 이참에 확실하게 알고 넘어가는게 좋을 것 같아 공부하면서 정리해놓기로 했다. 개발자 지향인데 이걸 모르면 개발자냐 소리 들을 것 같다. 

공부한 결과 RESTful API에대해 알기전에 REST, REST API를 먼저 이해해야한다. ( HTTP에대해 알고있다는 전제하.)

---

REST가 뭐지??

- REST는 Representational State Transfer의 약자로 직역하면 "대표 상태 전송"이며 애플리케이션 개발의 아키텍쳐중 하나입니다. 직역만 보면 저게 뭔소리람 이라는 생각이 듭니다. 

* 개념

 - HTTP URL을 통해 자원을 명시합니다.
 - HTTP Method를 통해 명시한 자원에 대한 CRUD를 적용합니다. 

* 구성 요소 

 - 자원 : HTTP URL 
 - 자원에 대한 행위 : HTTP Method
 - 자원에 대한 행위 내용 : HTTP Message Pay Load

아래의 코드는 학생때 했던 프로젝트중 일부인데 예시로 딱 좋아보여서 가지고 왔다. DataModel은 있는편이 이해하는데 도움이 될것 같아서 넣어놨다. 

/////////////////////////// DataModel.kt
data class R_SvaeInfo( //방문기록 응답
    var buildingid : Long?,
    var lastNoticeld : Long?
)

data class Saveinfo( //방문기록 저장
    var uuid : String,
    var major : String,
    var minor : String,
    var createdAt : String,
    var isEnter : Boolean
)

///////////////////////////APIS.kt
@POST("/record")
@Headers("accept: application/json",
    "content-type: application/json",
   )
fun userVisit(
    @Header("Authorization") authorization : String,
    @Body jsonparams: Saveinfo
):Call<R_SvaeInfo>

위의 예시에서 구성요소를 찾아보자. 2번째 APIS.kt만 보면 될 것 같다. 

 - 자원 : HTTP URL ("/record")
 - 자원에 대한 행위 : @POST
 - 자원에 대한 행위 내용 : 서버에서 구현됨. (POST는 데이터 저장하기위한 HTTP Method로 서버에서 DB에 Create하기위한 로직을 구현합니다.)

여기까지 보면 "아 REST는 클라이언트에서 url로 서버에 HTTP Method요청하면 서버가 처리한후 반환하는 것이구나" 정도로 이해가 된다. 

REST의 특징

1. Server-Client구조
 - Server : 자원을 가지고 있음. API를 제공하고 요청에대한 처리 및 저장을 책임진다.
 - Client : 자원을 요청함. 사용자에 대한 처리를 담당함. 
즉 서로간에 역할구분이 분명하고, 의존성이 줄어든다. 

2. Stateless 무상태성
 - HTTP를 사용하기때문에 Stateless의 특성이 보장된다. 
 - Server는 단순하게 클라이언트에 대한 요청을 처리만 한다. 
(Stateless는 클라이언트의 상태를 서버가 보존하지 않는 것. 즉 이전에 클라이언트가 무엇을 요청했는지 요청한 후 어떻게 변했는지 서버는 저장하지 않음.)

3. Cacheable
 -  HTTP라는 기존 웹 표준을 그대로 사용하기 때문에 HTTP가 가진 캐싱 기능이 적용 가능
(이 특징은 아직 잘 모르겠다. "Last-Modified” 태그나 E-Tag"라는 것이 나오는데 처음 보는 것이다. 그냥 봤을때는 최근 값??이런거를 server에 요청할 때 추가하는것 같은데 더 공부하고 이해한 후 추가예정)

4. Layered System
 - Client는 Server만 호출한다. (즉 서버에 직접연결인지 중간서버를 통한 연결인지 모름.)
 - 하지만 서버는 다중 계층으로 구성될 수 있다. Server는 순수 로직을 수행하고 그 앞에 로드벨런싱, 암호화, 사용자 인증 등등 추가 할 수 있다.( 위 예시에서는 헤더에 토큰을 넣어 사용자 인증을 추가한 경우)

5. Self-Descriptiveness
 - 어떤 메서드에 무슨 행위를 하는지 REST API만 보고도 쉽게 이해할 수 있다. 
(위의 예시에서는 @POST("/record")만 보면 Server로 보내는 데이터를 저장한다는 것이 쉽게 알 수 있다.)

6. Uniform Interface
 - HTTP표준만 따른다면, 어떤 기술이든지 사용가능한 인터페이스 스타일.
(위에서는 HTTP + Json 형식으로 정의했는데 이 형식은 다른 언어에서도 사용가능. )

REST의 장점과 단점.

장점은 특징을 이해했다면 자연스럽게 알 수 있으므로 생략.

단점

1. 표준이 명확하지 않음. 

2. HTTP Method의 한계
 - CRUD의 단순한 행위만 지원한다.

3.  구형 브라우저에서는 지원해주지 못하는 동작이 많다. 
( 크롬에서는 지원되지만, 익스플로어에서는 지원불가한 경우가 많다)

4. 브라우저를 통해 테스트할 일이 많은 서비스라면 쉽게 고칠 수 있는 URL보다 Header 정보의 값을 처리해야 하므로 전문성이 요구된다. ( 해본적이 없어서 그런가 잘 이해가 안간다. 더 알아보자)

---

REST API는 뭐지??

API : Application Programming Interface의 약자로 프로그래밍언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스이다. 

REST API : REST의 특징을 기반으로 API를 정의한것. (위의 예시에서는 APIS가 REST API가 된다.)

---

그럼 RESTful API는??

- REST의 설계규칙을 잘 지키면서 설계된 API를 말한다.(URL만 보고 어떤것을 요청하는지 한눈에 확인 가능)
좀 어렵게 말하면, RESTful API는 REST API이지만, REST API는 RESTful API라고 말할 수 없을 수 있다. 

2개의 url이 있다

https://meat.com/pig
https://meat.com/a

첫번째 URL은 돼기고지정보를 가져온다는걸 바로 알 수 있다. 이는 RESTful하다 라고 할 수 있다. 
두번째 URL은 뭔지 모른다. 뭘가져오는지 알 수 없다. 설계한 개발자만 알고 있겠지 이는 RESTful하지 않다 라고 할 수 있다. 

공부한 후에 내가 면접때 했던 답변을 생각해보니까 동문서답 수준이다. RESTful API를 설명하라했더니 REST특징중 하나를 설명하고있었네.. 특징도 아닌가 ㅎㅎ 면접관님께서 웃지 않으신게 다행이다. 웃으셨으면 바로 머리속이 텅텅 비어서 당황하지 않았을까 싶다 

- 중간에 잘못된 부분이 있다면 댓글로 남겨주세요. 수정하겠습니다.
- 더 알고계시다면 댓글남겨주세요. 큰 도움이 됩니다. 감사합니다!