일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | ||||
4 | 5 | 6 | 7 | 8 | 9 | 10 |
11 | 12 | 13 | 14 | 15 | 16 | 17 |
18 | 19 | 20 | 21 | 22 | 23 | 24 |
25 | 26 | 27 | 28 | 29 | 30 | 31 |
- 백준
- java
- 정렬알고리즘
- 파이썬
- 네트워크
- 서버
- 그리디알고리즘
- SQLP
- JQuery
- HTTP
- Python
- 프로그래머스
- SQLD
- 챗지피티
- 자바
- 개발자
- javascript
- 개발
- SQL
- 코딩테스트
- API
- codingtest
- ChatGPT
- jsp
- Spring
- 알고리즘
- 하루코딩
- 탐욕알고리즘
- HTTP상태
- 알고리즘코딩테스트
- Today
- Total
목록Back-end/Network (12)
개발자's Life

1. 쿼리 파라미터를 통한 데이터 전송 - GET 방식 - 주로 정렬 필터(검색어) 2. 메세지 바디를 통한 데이터 전송 - POST, PUT, PATCH - 회원가입, 상품주문, 리소스 등록, 리소스 변경 전송 4가지 상황 정적데이터 조회 - 쿼리 파라미터 미사용 : 보통 쿼리 파라미터 없이 리소스 경로로 단순하게 조회 가능 -> 이미지, 정적 테스트 문서 -> 조회는 GET 사용 동적데이터 조회 - 쿼리 파라미터 사용 -> 주로 검색, 게시판 목록에서 정렬 필터 -> 조회 조건을 줄여주는 필터, 조회 결과를 정렬하는 정렬 조건에 주로 사용 -> 조회는 GET 사용 -> GET 은 쿼리 파라미터 사용해서 데이터를 전달 HTML Form 데이터 전송 : Form 을 Submit 하면 태그 안 Input ..

HTTP 상태 코드란? 클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능 1xx(Informational) : 요청이 수신되어 처리중 (거의 사용 되지 않음) 2xx(Successful) : 요청 정상 처리 -> 정상적으로 요청이 처리 되었을 때 200번대로 응답 3xx(Redirection) : 요청을 완료하려면 추가 행동이 필요 4xx(Client Error) : 클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수행할 수 없을 때 400번대로 응답 5xx(Sever Error) : 서버 오류, 서버가 정상 요청을 처리하지 못함 200, 300, 400, 500 번대에 따라서 어떤 결과를 응답하였는지 파악하면 된다.

안전, 멱등 ,캐시가능이 있고 아래와 같이 정의가 된다. 안전 safe : 호출해도 리소스를 변경하지 않는다. GET, HEAD 제외하고 안전하지 않음 호출을 계속해서 로그가 쌓여 에러 발생하는 것은 고려하지 않는다. 멱등 Idempotent : 여러번 호출하든 결과가 똑같다. GET -> 여러 요청을 하여도 결과는 같다. PUT -> 기존을 날리고 새로운 것을 저장한다. 결과를 대체하여 최종결과는 같다. DELETE -> 몇번을 호출하든 삭제된 결과는 똑같다 POST -> 중복결제, 중복배송 등 두번 호출이 되면 안되기에 멱등하지 않다. 멱등이 중요한 이유는 만약 DELETE 메서드를 호출하고 서버에서 TIMEOUT 으로 응답을 정상적으로 못 주었을때 한번 더 요청을 할 수 있는데 멱등하지 않으면 다시..
HTTP 메서드 : GET, POST, PUT, PATCH, DELETE API URI 설계에서 가장 중요한건 리소스 식별! 이용자를 예시로 들었을 때 이용자를 등록/수정/조회 가 리소스가 아니고 회원 자체가 리소스다. 이용자 : USER 이용자 목록 조회 / user/{id} 이용자 조회 / user/{id} 이용자 등록 / user/{id} 이용자 수정 / user/{id} 이용자 삭제 / user/{id} URI 는 리소스 식별로 하자! GET : 리소스(레프리젠테이션) 조회, 데이터를 끌고 올때 사용 POST : 요청 데이터 처리, 주로 등록에 사용, 왼만하면 다 사용이 가능 PUT : 리소스(레프리젠테이션)를 보내게 되면 대체되어 버린다. 완전 새로 갈아버리는 느낌 PATCH : 리소스(레프리젠..
연결을 유지하는 모델 Client 에서 Server 에 요청하고 Server 에서 응답하고 계속 유지한다. 연결을 유지하지 않는 모델 Client 에서 Server 에 요청하고 Server 에서 응답하고 끊어 버린다. -> 1시간 동안 수천명이 사용하더라도 요청하고 응답 후 유지하지 않으면 서버 자원 관리가 용이하다. -> 단점은 TCP/IP 를 새로 맺어야하고 3Way HandShake 시간이 추가된다.. HTTP는 기본이 연결을 유지하지 않는 모델이였지만 지금은 지속 연결(Persistent Connections) 로 문제 해결 지속 연결이 없을 경우 아래와 같이 진행이 된다 연결 요청 - HTML 응답 종료 연결 요청 - 자바스크립트 응답 종료 지속연결이 있을 경우 아래오 같이 진행된다. 연결 요청..
Stateless -> 서버가 클라이언트 상태를 보존하지 않는 것! -> 서버가 이전 상태를 기억하지 않는것 1. Client : "물 얼마인가요?" -> Server : "500원 입니다." 2. Client : "물 3개 주세요" -> Server : "1,500원 입니다." (이전 상태 기억 x) 3. Client : "물 3개 현금으로 구매할게요" -> Server : "현금으로 구매완료 했습니다."(이전 상태 기억 x) 장점 : 무상태는 클라이언트 요청이 많이 증가하여서 무한히 서버 증설이 가능 : 스케일 아웃 - 수평 확장 유리 단점 : 로그인 상태를 유지해야 하는 경우에는 사용하기 힘듬 Stateful -> 서버가 클라이언트 상태를 보존 하는 것! -> 서버가 이전 상태를 기억하고 있는것. ..