HTTP(stateful, stateless, connectionless)

무상태 프로토콜(stateless)

stateful(상태 유지)

• 서버가 클라이언트의 이전 상태를 유지하는 것이다.
• 중간에 다른 점원으로 바뀌면안된다 -> 다른 점원으로 바뀔때 상태 정보를 다른 점원에게 알려줘야한다, stateful이기때문에 상태유지기라서!!!!
• 항상 같은 서버로 유지 되어야한다 이러한 상황에서 서버가 장애가 나면 통신이 장애가 발생한다.

• 고객 : 이 차가 얼마죠?
• 점원 : 2억입니다. (차라는 상태를 유지)

• 고객 : 2대 두개하겠습니다.
• 점원 : 4억입니다. 신용카드, 현금 어떤 걸로하시겠습니까 (차, 2대라는 상태 유지)

• 고객 : 신용카드로 구매하겠습니다.
• 점원 : 결제완료 (차, 2대, 신용카드)

• stateful은 중간에 점원이 바뀌게 된다면 꼬이게 된다.. 해당 정보를 처리한 상태를 하기때문

stateless

• 중간에 점원이 바뀌어도 괜찮다
• 클라이언트의 요청이 증가해도 서버를 대거 투입 가능하다
• 무상태응답은 서버를 쉽게 바꿀 수 있다 -> 무한 서버 증설 가능
• 하나의 서버가 장애가 나더라도 다른 서버가 요청을 처리해서 응답을 보낼 수 있다
• 무상태는 수평확장에 유리하다(스케일 아웃)
• ex: 이벤트를 할때 이벤트페이지에 서버를 쫙 늘리는 경우가 있다.

 

그러나 stateless 한계

• 로그인이 필요없는 것은 무상태로 설계가 가능하지만, 로그인이 필요한 경우에는 stateful로 상태유지를 해주어야한다
• 브라우저 쿠키와 서버 세션등을 사용해서 상태를 유지한다
• stateless단점 중 하나는 데이터를 보낼 것이 너무 많다... 모든 정보를 계속 보내야하니.

http메서드 특정

• safe 안전
  • 호출을 해도 리소스가 변경이 되지않는다면 안전하다고 본다, get은 조회를 하니 리소스가 변경이 되지않아서 안전하다 포스트는 주어진 데이터를 처리하니 safe하지않다.
  • 계속 호출하면 서버에 로그가 쌓이는 것은 고려하지않는다(해당 리소스만 고려한다)
• 멱등(Idempotent)
  • 몇번을 호출하든 결과는 똑같은 것이다.
  • GET(), PUT(기존에 있던 것들 날리고 덮는 것이라서, A를 한번 PUT하든 10번하든 A를 PUT하는 것이다)
  • POST는 멱등하지 않다 왜냐하면 (주문을 10, 100번 하면 결과는 다르다!)
  • 멱등은 외부 요인으로 중간에 리소스가 변경되는 것까지는 고려하지는 않는다 (중간에 GET을 하다가 PUT -> GET을 해서 리소스가 변경 될 수 있는데 그것은 고려하지않는다)
  •  
• 캐시가능 (cacheable)
  • 캐시를 할려면 key값이 일치해야하는데 post는 바디안의 것을 키로 할려면 복잡하다 그래서 get은 url 값만 가지고 key를 받아들여서 get은 일반적으로 캐시가 가능하다.
  • GET, POST, PUT, PATCH가 가능은한데 실제적으로는 GET정도만 캐시를한다.

HTTP

동적조회

• 주로 검색, 목록에서 정렬필터, 조회 조건을 줄여주는 필터, 조회 결과를 정렬하는 정렬 조건에 주로 사용
• 조회는 GET
•  

HTML Form 데이터 전송

• post가 데이터를 변경하는 것이 있다고만 알면안된다!!!!
• form의 내용을 메시지 바디를 통해서 전송한다(쿼리파라미터 형식)
• 전송 데이터를 urlencoding 처리한다 ( abc김 -> abc%..)
• HTML Form은 get, post만 지원한다
• 파일 업로드 같은 바이너리 데이터 전송시 get전송도 사용한다(multipart/form-data)

HTML Form 데이터 전송

• multipart/form-dta(주로 바이너리데이터 전송시 사용)
  • 이름이나 나이 텍스트뿐만아니라, 이미지파일도 같이 보낼 때, multipart/form-data를 쓴다
  • content-Type: multipart/form-data로 들어가고, boundary=---xxxx면서 경계가 잘린다..
  • multipart이다 여러개의 파트로 나눠서 데이터를 보낼 수 있게된다.
  • 그림..

post랑 put의 차이

• post는 자세한 정보가 없다 /members까지로 끝이다
• put은 /members/1을 변경하겠다고 명시가 가능하다..
• post
  • 클라이언트는 등록될 리소스의 URI를 모른다 ( post /members)
  • 서버가 새로 등록된 리소스 URI를 생성해준다 (Location: /members/100
  • 컬렉션
    • 서버가 관리하는 리소스 디렉토리, 리소스의 URI를 생성하고 관리한다, (ex : /members )
• put 기반 등록
  • 파일 등록 /files/{filename} (파일 업로드할때 기존 파일이 있으면 지우고 새로 업로드하니 정확하다)

HTTP API 설계 예시

• POST도 데이터 변경, PUT도 변경 차이점을 명확히 알자!
• API설계시 resource를 중점적으로 둬서 설계한다
• 회원목록, 등록, 조회, 수정, 삭제.. 회원의 정보를 건드리는 것이다. 여기서 리소스는 회원!
• /members/~로 거의 모든 것이 가능하다
• 회원 목록 -> /members (get)
• 회원 등록 -> /members (post)
• (게시판에서 )게시글을 다시 쓸때는 put을 사용하면된다 (다시 사용하는 것이니 덮으면된다)
• 애매하면 post를 쓰면된다 post는 거의 무적이다
•  

출처 : 김영한님 http강의