거북목 개발자

나는 누구인가? 자신을 아는것이 성공의 시작 우리는 '과거'를 반복한다 -> 매일이 과거의 생각,감정,지식들이 오늘과 미래에도 그대로 계속해서 무한루틴한다. -> 내 안의 불안, 부정감정이 그대로 미래에 투영하고 반복한다. "거봐 안되잖아"의 믿음이 편안함을 가짐. '실패'는 가장 확실하기 때문에. -> '현재의 나'는 과거의 생각과 감정이다 어제했던 90%의 생각이 그대로 지속, 반영된다 나는 지금 어떤 '무드'에 있나? -> '무드 미터' 생각 -> 선택 -> 경험 -> 감정 -> 생각 내 한계가 어디까지인지 본인도 모름 -> '울트라 셀프'는 나 자신을 바꾸는것 '감정'이 '무드'가 되고 무드가 '기질'이 되고 오래두면 '성격'이 된다. 1. 생각 : 어제했던 생각을 2.선택 : 어제의 생각이 어제..

1. 웹 브라우저가 id, password를 담아 서버에 로그인을 요청함 2. 서버는 id, password 검증에 성공하면, 해당 사용자에 대한 sessionId(쿠키)를 생성함 3. 서버는 Set-Cookie에 sessionId를 담아 '웹 브라우저'에 '로그인 성공'을 응답함 4. 웹 브라우저는 '쿠키 저장소'에 sessionId(쿠키)를 저장함 5. 이후 웹 브라우저가 쿠키에 접근가능한 도메인에 요청을 보낼 때마다 자동으로 쿠키 저장소에서 꺼낸 sessionId(쿠키)를 Cookie에 담아 서버에 요청을 보냄 6. 서버는 sessionId(쿠키)의 유효성을 검사해 클라이언트를 식별함

-> 201은 리소스를 새로 저장하고 저장된 경로를 Location에 포함해서 반환하며 '응답 메세지'에 본문을 첨부해도 된다. -> 204는 No content. '응답 메세지'에 본문을 첨부하면 안된다. 저장이 성공했고 결과 데이터를 반환할 일이 없을 때 사용하면 된다. 화면은 계속 유지해야 하기 때문에 -> 200: 새롭게 업데이트한 페이지를 보여줘야 할 때 : GET, PATCH -> 201 : 리소스를 신규로 생성했을 때 : POST -> 204 : 사용자에게 보여지는 페이지를 바꾸지 않고 리소스를 업데이트 할 때 : PUT 1. 302 - 메서드가 GET으로 변할 수 있음 2. 307 - 메서드가 변하면 안됨 3. 303 - 메서드가 GET으로 변경됨 -> 현실적으로 307, 303을 권장하지..

1. 리소스를 식별하여 리소스만으로 URI를 설계한다. 2. 문서, 컬렉션, 스토어로 해결하기 어려운 상황의 경우 컨트롤 URI를 사용한다. -> 주로 '컬렉션'을 많이 사용하고 파일/게시판 같은 경우에 '스토어'를 사용할 수 있다. -> 문서, 컬렉션, 스토어로 해결하기 어려운 추가 프로세스를 실행할 때, 컨트롤 URI를 사용한다. Q. 데이터 전송의 경우 2가지 방식중 어떤 방식을 실무에서 선호하는가? 1. HTML Form이 메인, 필요에 따라 AJAX(HTTP)를 통한 PUT, PATCH,DELETE 활용 2. 애초에 AJAX(HTTP API)를 메인으로 활용 -> 두 방식 모두 잘 사용하고 다만 사용하는 상황이 서로 다를 뿐이다. form..

Q. HTTP Form과 HTTP API의 차이점은? -> 응답결과로 무엇을 전달받느냐에 따라 크게 2가지로 나눌 수 있다. 1. HTML을 전달받는 것 2. 데이터를 전달받는 것 HTTP API는 응답결과로 HTML이 아닌 데이터를 전달받는것을 말한다. Q. GET으로 '게시판 글 조회'를 할 때 글 조회수가 올라가도록 구현하는 것이 '멱등성'을 위반하게 되는 것인가? 그렇다면 GET이 아닌 POST로 구현해야 하는가? -> 이런 부분이 조금 모호하기는 하지만, 이런 경우엔 GET을 사용하는 것이 맞다. 조회수가 올라가는 부분이 게시글 자체의 리소스를 변경하는 것이 아니기 때문이다. 애플리케이션 내부의 로그를 남기는 부분에서 GET을 사용하는 것도 모두 허용된다. -> 반드시 '조회..

Q. DELETE 메서드를 호출해 파일을 삭제한다고 가정했을 때, 2번째 호출의 응답을 어떻게 하는것이 코드 레벨에서 좋은 설계인가? - 클라이언트에서 파일 삭제를 요청, 서버에서 성공했으나 정상응답을 주지 못함 - 클라이언트는 정상 응답을 받지 못했으니 재요청을 함 재요청을 했을 때 서버는 2가지 방식으로 응답할 수 있을 것 같다. 1. 이미 삭제된 파일을 삭제하라고 하는 요청이니 "파일이 존재하지 않습니다"같은 오류메세지와 함께 오류 코드를 응답한다. 2. 이미 이전 요청에서 삭제된 파일이지만 현재 파일은 삭제된 상태이므로 삭제를 성공했다고 응답한다. '멱등'은 클라이언트의 관점이 아닌 '해당 리소스 관점'에서 보는 것이다. 1,2 번 방식 둘다 리소스 관점에서 삭제된 상태이므로 어..

Q. /orders/{orderId}/start-delivery 는 '배달 상태 변경'의 의미에서 POST가 아닌 PATCH를 사용해야 하는것 아닌가? -> '배달 상태'를 변경한다는 것은 단순히 해당 리소스의 값을 변경하는 정도로 끝나는 것이 아니라, 내부에서 매우 큰 프로세스가 실행된다. 이렇게 해당 리소스만 변경하는 것이 아니라 '내부 프로세스를 실행해야할 때'는 PATCH보다 POST를 사용하는 것이 좋다. 단순히 회원 정보를 변경하는 것처럼 '특정 리소스의 데이터를 병경할 때'는 PATCH를 사용하는 것이 좋다. Q. GET 메서드를 사용해 복수 개의 리소스를 조회할 때, URI를 어떤식으로 설계하는것이 좋을까? -> 예를 들어, id가 3,4,5,인 회원을 조회하고 싶다면 p..

Q. members/1이 아니라 members?id=1 이런식으로 써야하는 것 아닌가? -> path와 query는 리소스를 식별하기 위해 함께 쓰인다. query를 써서 members?id=1과 같이 사용할 수도 있지만 관례적으로 리소스를 식별할 때 id(식별자)는 members/1과 같이 path를 사용한다. -> path는 주로 계층구조로 된 정보를 포함하고 query는 주로 비계층구조로 된 정보를 포함한다. 즉, path는 리소스의 위치를 특정해서 보여줘야 하는 경우 사용하고, query는 리소스를 정렬/필터해서 보여줘야 하는 경우 사용한다. path - /members/1 query - ?members?occupation=programmer