일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- www-Authenticate
- Expires
- no cache
- 서블릿필터
- hikaricp
- 쿠키생명주기
- http
- 프록시 캐시 서버
- gradle오류
- 조건부요청
- 300
- 프록시객체
- HTTP상태코드
- must revalidate
- resolveArgument
- 캐시
- UrlResource
- max age
- 서블릿http세션
- etag
- 검증헤더
- HTTP API
- Could not find or load main class worker.org.gradle.process.internal.worker.GradleWorkerMain
- 세션타임아웃설정
- supportParameter
- 양쪽 모두 값 설정
- Not Modified
- 세션만들어보기
- 인증체크
- 쿠키보안문제
- Today
- Total
목록HTTP API (2)
복습을 위한

HTTP API를 어떤식으로 URI를 설계하는지 예시로 알아보자(바람직하게) 크게 POST기반 등록 PUT 기반 등록이 있다. 리소스를 식별하는 것은 '리소스'를 식별하는 것이 중요하다. 미네랄을 캐다에서 미네랄이 중요한 것이다. 수정같은 경우 고민을 좀 해봐야한다. PATCH는 부분적으로 수정할 수 있다. PUT은 아예 덮어버릴 때이다. 보통은 PATCH를 추천한다. PUT같은 경우 게시글 같은 것을 수정할 때 좋을 거다. 전부 다 갈기 때문이다. 애매할 때는 POST를 쓰자 POST의 자원 등록 특징은 서버가 새로 등록된 리소스 URI를 생성해준다. POST에 대해 포스팅을 할 때 설명했다. 서버에서 받은 유저정보를 데이터베이스에 저장하고 응답데이터로 새로 등록된 리소스 URI를 넘겨준다. 이런 형식..

클라이언트에서 서버로 데이터 전송 (데이터 전달 방식은 크게 2가지로 나눌 수 있다.) • 쿼리 파라미터를 통한 데이터 전송 • GET • 주로 정렬 필터(검색어) • 메시지 바디를 통한 데이터 전송 • POST, PUT, PATCH • 회원 가입, 상품 주문, 리소스 등록, 리소스 변경 클라이언트에서 서버로 데이터를 전송하는 상황은 네가지로 나뉜다. 먼저 정적데이터조회를 살펴보자 이미지나 정적 텍스트 문서가 해당된다. GET으로 URI경로를 보내면 서버에서 받아서 그 해당경로로 약속되어있는 리소스를 클라이언트에게 내려준다. 추가적인 쿼리데이터나 파라미터가 필요없다. • 이미지, 정적 텍스트 문서 • 조회는 GET 사용 • 정적 데이터는 일반적으로 쿼리 파라미터 없이 리소스 경로로 단순하게 조회 가능 다..