Rest?
HTTP 통신에서 어떤 자원에 대한 CRUD 요청을 URL과 Method로 표현하여 특정한 형태로 전달하는 방식
History
비유) 강남대로 만들때, 차가 많이 없는데 이렇게 크게 지어도 돼? 지금 막힘. 테헤란로도 짓고... 근데도 막힘. 어떻게 해야할지 고민. 좌회전 신호 짧게 바꾸고 등등 해서 나아짐
HTTP 프로토콜 고안할때만해도 널널할줄 알았는데 유저가 엄청 많아짐. 그 당시 컴퓨터가 개인이 가진다는 인식을 하지 못했음. (빌게이츠, 스티브잡스가 일반 개인이 컴퓨터를 쓰려면 싸고, 작고 쉬워야한다는걸 해냈음)
HTTP 통신이 포화되었다라고 예측이 되었을때, 버리고 새로 가야한다는 움직임이 있었음.
새로움? ex : IPv4가 바닥이 났기때문에 IPv6로 넘어가야한다가 결론
하드웨어, 기술 포화상태. 여러가지 연구결과 ⇒ 그 중 하나가 REST.
WWW 바꿔야한다. 새로운 망을 만들어서 REST라고 하자. ⇒ 실패
why? 초기 REST는 URL과 Method로 표현하는게 메일발송,회원가입이 불가했음
그중 일부 차용, HTTP 새롭게 가볍게 쓰기 위해 JSON 방식 쓰는걸로 바꿈
JSON 쓰면 HTML과 달리 쓸데없는 태그, 텍스트 아낄수있음!
정리
WWW에 HTTP통신으로 대표되는 네트워크 망이 포화, 차세대 네트워크 망 필요성 대두. REST 나타남. URL, Method 쓰자. 메일발송, 회원가입 불가해서 GET, POST만 가져다씀. JSON이랑 엮어서 씀. 이러니 네트워크 안바꿔도 되더라. 아직은 기존의 망에 새로운 레스트 기술을 혼용해서 쓰고 있음.
WAS(Web Application Service) vs REST
- 기존 방식. 웹브라우저가 파라미터랑 URL 전달하면 거기에 해당하는 기능이 이 파라미터를 받아서 있는지 없는지 체크, 데이터 CRUD 실행, 그리고 텍스트 기반의 HTML로 전달해줌.(패스트푸드점 직원, 주문 잘못되면 직원책임) WAS는 웹브라우저가 렌더링만함
- REST는 요청,응답 통로만 제공해줌. 처리는 프론트(웹브라우저)가 함. (패스트푸드점 키오스크, 주문 잘못하면 내책임) REST 만들긴 어렵지만 해놓으면 쓰기 편함. 한마디로 JSON 보내주는거라 볼 수 있음. REST는 UI 를 클라이언트가 구성함.
REST with Ajax
Map 구조로 JSON 리턴, 받아다가 클라이언트측에서 핸들바 사용해서 만듬
파라미터 받고 DB입출력하는건 똑같은데 결과물 전달해주는 방법만 다름
template
{"rt" : "result text",
"item" : {
"key1" : "value1",
"key2" : "value2",
.
.
.
},
"pubDate" : "yyyy-mm-dd hh-mi-ss"
}반드시 해야하는건 아니나 규격을 정해놓으면 처리가 빨라짐
pubdate? ⇒ 결과구조가 똑같으면 인식을 안해버림. 다른 시간값을 넣어주면 인식 잘하니까. (캐시처리 방지)
rt : 디버깅을 잘하려면 에러시 어떤 메세지를 띄울지 정하는게 중요함
