의식의 흐름대로 정리한 HTTP, REST

#HTTP

HTTP란
Hyper Text Transfer Protocol
하이퍼텍스트를 전송하는 규약

##하이퍼텍스트

텍스트를 초월
문서의 연결성 + 서식 넣을 수 있음 (a태그같은 마크업랭귀지)

##텍스트

는 문자

##하이퍼링크

연결성
문서와 문서 연결

---

#Transfer Protocol

##Transfer

전송

##이메일은 SMTP

Simple Mail Transfer Protocl
이메일 전송 규약

##이메일 특징

발신자 수신자 제목 내용
잘 주고받을라고 규약 만듦

##HTTP 프로토콜

이메일은 개인과 개인임
어쨌든 내가 1000명한테 보내고 싶으면 1000명한테 메일써야함... 무리무리
서버에 띄워놓고 알아서 가져가게 하면 좋겠음
그래서 만든거.

배포자는 1명이지만 받는사람은 여럿
내가 주소를 열면 사람들이 그 주소로 들어와서 볼수있음(배포)

HTTP 프로토콜은 이걸 해결하려고 만든거

##HTTP 주소 = 리소스

HTTP 주소를 리소스라고 말함
가져갈 자원이 여기 있으니까

하나의 서버에서 많은 사람에게 배포하기 위한 솔루션임

##HTTP request 메소드

식당
식당에 가서 주문을 함 (무슨 요리 주세요) = GET 요청
스테이크 1인분이면 URL은 스테이크/1

응답으로 스테이크 1인분이 옴 = Response

은행
은행 계좌 지워주세요 = DELETE 요청
DELETE/내계좌

은행에 돈 넣고싶음 = POST 요청
은행에 돈을 넣으려면 내가 돈을 담아서 줘야함

그냥 요청만 보내고 싶을 때는 GET으로 충분하지만, 안에 내용물을 넣어서 줘야하면 POST를 씀
내가 어느 주소, 자원에 접근하는건 GET으로 충분하지만..

---

#REST

이런 규칙을 더 엄격하게 쓰자고 해서 REST라는게 나옴
HTTP가 처음 나왔을 떈 좀 허술했음.
사람들이 아무렇게나 함
어차피 돈도 GET 주소에다가 넣어버리면 돈을 저금할 수 있다고 생각하고 막 그렇게 짜버림
그럼 돈이 얼마인지 등의 중요한 정보들이 노출이 돼버림
GET은 공개된 상태로 요청을 보내는게 기본이라서.

그리고 글자수 제한도 있음
웨이터한테 주문할때 엄청 복잡하게 주문하면 힘드니까

GET으로도 주소 뒤에 파라미터를 막 넣으면 정보를 넣을 수 있기 때문에 POST로 보낼걸 GET으로 잘못 많이 보냈었음

그래서 로이필딩이라는 사람이 HTTP는 원래 이런 의도로 만들었고 이렇게 써야한다고(RESTful 하게 써야한다고) REST라는 용어를 정의했음

그 내용이 결국 HTTP를 (스펙에 맞춰) 바르게 쓰자임
엄격하게 주소를 만들고 엄격하게 방식을 사용하고

##RESTful 하다는건

어떤 주소가 정확하게 어떤 리소스에 접근할 수 있는 유일한 주소여야 하고
목록을 나타내는 주소는 어떤 모양이여야 하고
그 목록에다가 POST 요청을 하면 그 목록에 아이템이 추가가 돼야하고
아이템 주소에서 PUT이나 DELETE를 해야하고

등등의 팍팍한 규칙들을 지켜야하는거

##내가 REST 라이브러리를 썼는데 RESTful 하지 않게 잘못 사용하면 생기는 문제

REST에 맞춰서 만든 다른 프로그램들이 작동을 안함
REST니까 새로 생성할땐 POST라고 생각하고 보냈는데 GET으로 썼으면 작동을안함