Day 33
1. HTML 기본
좋은 URI 설계?
가장 중요한 것은 ==리소스 식별==
리소스란 무엇인가
회원을 등록, 수정한다고 가정하면 리소스는 회원이다.
등록과 수정은 행위다.
회원이라는 리소스만 URI에 매핑!
리소스만으로 매핑을 하면 구분하기가 어렵다.
그래서 행위를 HTTP 메서드로 구분하여 같은 URI라도 행위를 통해서 구분이 가능하다.
HTTP 메서드
GET
- 리소스 조회
- 전달하고 싶은 데이터는 query를 통해서 전달
- GET에서 메시지 바디를 사용할 수 있지만 권장하지 않음
POST
- 요청 데이터 처리
- 메시지 바디를 통해 서버로 요청을 전달
- 서버는 요청 데이터를 처리
요청 데이터를 처리하는게 무슨 말일까?
-
- 데이터 변경
- 데이터를 넘어서 프로세스를 처리해야 하는 경우
- 다른 메서드롤 처리하기 애매한 경우 (무적임)
PUT
- 리소스를 대체, 없으면 생성
- 파일을 복사하고 붙여넣는거랑 같음
- 클라이언트가 리소스 식별 (URI를 통해서 식별이 가능)
주의 : 리소스를 완전히 대신한다.
수정이 아니라 완전히 갈아치우는 것
PATCH
- 리소스 부분 수정
- 지원이 안되는 서버도 있음
DELETE
- 데이터 제거
HTTP 메서드의 속성
- 안전
- 멱등
- 캐시가능
안전 Safe
- 호출해도 리소스를 변경하지 않는다.
멱등 Idempotent
- 한 번 호출하든 백 번 호출하든 결과가 똑같다.
- 외부 요인으로의 변경은 고려x.
- GET, PUT, DELETE 는 멱등하다.
활용 (자동 복구 메커니즘)
서버가 타임아웃으로 응답을 못주었을 때, 같은 요청을 해도 되는가?
캐시가능 Cacheable
- 응답 결과 리소스를 캐시해서 사용해도 되는가?
- GET,HEAD,POST,PATCH 가능
- 실제로는 GET, HEAD만 사용 (캐시 키로 고려해야하기 때문에)
- POST,PATCH는 본문도 있어서 하기 힘듦
2. JPA 심화
1.영속성 컨텍스트란?
엔티티를 영구 저장하는 환경. 엔티티 매니저가 소유하고 있음.
애플리케이션과 데이터베이스 사이에서 객체를 보관하는 가상의 데이터베이스 역할.
엔티티 매니저를 통해 엔티티를 조회,저장시 엔티티를 보관,관리.
"영속화한다" -> "매니저가 영속성 컨텍스트에 넣어준다"
영구화란?
![]()
엔티티의 영구 저장 공간은 물리적인 개념이 아니라 논리적인 개념이다.
- 실제로 물리적으로는 트랜잭션 단위의 휘발성 메모리 공간
JPA 엔티티의 상태
- 비영속 (New)
- 영속성 컨텍스트와 관계가 없는 상태
// 엔티티를 생성
Member minsook = new Member();
member.setId("minsook");
member.setUsername("민숙");
- 영속 (Managed)
- 엔티티 매니저가 엔티티 컨텍스트에 저장해서 관리되는 상태
// 엔티티 매니저를 통해 영속성 컨텍스트에 엔티티를 저장
em.persist(minsook);
- 준영속 (Deteached)
- 영속성 컨텍스트에서 관리되다 분리된 상태
// 엔티티를 영속성 컨택스트에서 분리
em.detach(minsook);
// 영속성 컨텍스트를 비우기
em.clear();
// 영속성 컨택스트를 종료
em.close();
- 삭제 (Removed)
- 영속성 컨텍스트에서 삭제된 상태
em.remove(minsook)
- 영속성 컨텍스트에서 삭제된 상태

'항해99 > TIL | WIL' 카테고리의 다른 글
| WIL (4주) (0) | 2023.02.12 |
|---|---|
| 2023.02.11 (34일) (0) | 2023.02.12 |
| 2023.02.10 (32일) (0) | 2023.02.10 |
| 2023.02.08 (31일) (0) | 2023.02.08 |
| 2023.02.07 (30일) (0) | 2023.02.07 |