돋 돋

HTTP API 설계 예시 (2가지 종류 있어! -> POST, PUT) - HTTP API - 컬렉션 POST 기반 등록 예) 회원 관리 API 제공 - HTTP API - 스토어 PUT 기반 등록 예) 정적 컨텐츠 관리, 원격 파일 관리 - HTML FORM 사용 웹 페이지 회원 관리 GET, POST만 지원 자 [ 회원 관리 시스템 ] 을 만든다고 생각해봐 URI(리소스)를 식별하는건 -> 항상 리소스를 식별해야지 다른걸 식별하면 안돼! 회원 목록 /members -> GET 회원 등록 /members -> POST 회원 조회 /members/{id} -> GET 회원 수정 /members/{id} -> PATCH, PUT, POST (PATCH : 부분적으로 수정) (PUT : 완전히 덮기) (P..

1. 이번주에는 task 리뷰를 많이 했으면 좋겠다. 고로, 야근을 해도 될듯. 메뉴끼리 조금만 더 통일성 있게 , 쓸데없는 (중복되는) 코드는 빼자....다음은 없다.....한번에 끝내자.. 물론 콜라비에 잘 기록해서 뭐했는지 잘 적어둬서 티도 좀 내주고ㅎ 2. 그래서 조금 구체적으로는 엣지, 장치관리 페이지 전체적인 리팩토링을 (개인적으로 시도해서) (리뷰까지 해보고 괜찮으면) 진행해보는거로 ( 부가적인거니까 야근 이용 ) , 할당된 task 는 제발 업무시간내에 끝낼 수 있도록!@!@! 3. 백엔드 과외(?)가 다음주부터 시작될 예정... 나를 백엔드에 투입하려는 팀의 의지ㅎㅎㅎ 그전에 http강의는 끝내고 가야할거같다. 이번주 완강 예정 4. 토요일까지 알고리즘 문제 ..

-주간 계획부터 1. 알고리즘 - 1단계 문제 풀기 2. 함수형 chapter2 듣고 정리 3. http - section5 정리 4. modal, validation, toast 태스크 완료 5. 프로젝트 생각해봐.............제발 6. 리팩토링?(생각해보기) ⭐︎FACTS⭐︎ 1. opcua, mqtt.. 업무에 필요한 통신 프로토콜 공부를 하는 중이다. 블로그를 참고하고 회사 노트에 작성하기. 2. 업무 중 멘탈이 나가는 경우 -> 안되는거 보지말고 나중에 공부하려고 적어뒀던 리스트를 하나씩 검색하면서 공부하기 -> (mqtt, opcua, docker) 3. 회사 코드가 익숙해질수록 전반적인 리팩토링의 필요가 느껴진다. 만질것인가? 급한만큼만 수습할 것인가? 4. 몸 컨디션 안좋음 ⭐︎..

⭐︎FACTS⭐︎ 1. 업무 외 시간 중 투입한 시간이 절대적으로 부족 ( 재택하며 인천에 빈둥, 목요일은 야근) 2. 함수형 프로그래밍 강의 (es5) 스터디 끝 / 다음주부터 es6 강의로 시작 3. 자바스크립트 알고리즘 강의 & 문제 풀이 & 스터디 시작 4. 수영 시작 !!!!!!!! ⭐︎FEELINGS⭐︎ 1. 한게 없는거 같아 너무 시간 버린 느낌.. 2. es5의 경우 맛만 본 느낌. 실제로 써먹어보는 경험이 필요할듯 3. 기본 부분인데 막히네? ⭐︎FINDINGS⭐︎ 1. 포트폴리오 중 하나가 지금 제품 만드는거니까 야근은 환영, 목표를 좀 더 잡을 필요가 있지 않나? 2. 그래도 스터디 하면서 2번 말하는 발표 하니까 첫번째와 두번째 말하는게 달랐음. 이것도 연습하는 느낌! 3. 여기에 ..

⭐︎FACTS⭐︎ 1.인프런 강의 48.78% 강의 수강 -> 블로그 포스팅 중 2.애플코딩 강의 수강 (완강 못하고 수강 종료) 3.회사에서 CSS 관련한 태스크를 받았고 -> 혼자 해결하지 못하고 지인에게 물어봐서 해결 4.회사에서 local 환경을 docker를 이용한 개인 db 환경으로 세팅. 5.이름 등록시 중복된 값인지 확인하고 validation 주는 작업을 해야함 -> 못함!!!! 6.질문을 계속 어려워한다 -> 마인드 세팅의 필요성? ⭐︎FEELINGS⭐︎ 1.CSS 영역도 진짜 넓고, 엄청난 기능이 많다는걸 진짜 찐으로 느낌 (해결방법이 ::after 를 사용한 배경화면 설정인데... ::after 알자알자 하다가 모르고 넘어갔던 부분..) 2.postman, vm, docker 관련해..

HTTP API 설계 예시 회원 관리 시스템 API 설계 - POST 기반 등록 ⏺ 회원 목록 /members -> GET ⏺ 회원 등록 /members -> POST ⏺ 회원 조회 /members/{id} -> GET ⏺ 회원 수정 /members/{id} -> PATCH, PUT, POST ⏺ 회원 삭제 /members/{id} -> DELETE URI! 항상 리소스를 식별해야쥐

HTTP 메서드 활용 클라이언트에서 서버로 데이터 전송 - 전달 방식은 크게 2가지 1. 쿼리 파라미터를 통한 데이터 전송 ⏺ GET ⏺ 주로 정렬 필터(검색어) 2. 메시지 바디를 통한 데이터 전송 ⏺ POST, PUT, PATCH ⏺ 회원 가입, 상품 주문, 리소스 등록, 리소스 변경 - 4가지 상황 ⏺ 정적 데이터 조회 🔘 이미지, 정적 텍스트 문서 🔘 조회는 GET 사용 🔘 정적 데이터는 일반적으로 쿼리 파라미터 없이 리소스 경로로 단순하게 조회 가능해~ ⏺ 동적 데이터 조회 🔘 주로 검색, 게시판 목록에서 정렬 필터(검색어 같은 추가조건들 -> 쿼리 파마리터 사용 (q=hello&hl=ko)) 🔘 서버에서 쿼리 파라미터를 기반으로 정렬 필터해서 결과를 동적으로 생성 🔘 조회 조건을 줄여주는 필터..

⏺ 🔘 HTTP 메서드 ->가장 중요한 것은 리소스 식별! - 리소스의 의미는? 🔘 회원을 등록하고 수정하고 조회하는게 리소스가 아니다 🔘 (예) 미네랄을 캐라 -> 미네랄이 리소스 🔘 회원이라는 개념 자체가 바로 리소스! - 리소스를 어떻게 식별하는게 좋을까? 🔘 회원을 등록하고 수정하고 조회하는 것을 모두 배제 🔘 회원이라는 리소스만 식별하면 된다. -> 회원 리소스를 URI에 매핑 요구사항 - 회원 정보 관리 API를 만들어라! -API URI 설계 : 리소스 식별, URI 계층 구조 활용 🔘 회원 목록 조회 / members 🔘 회원 조회 / members/{id} ->어떻게 구분하지? 🔘 회원 등록 / members/{id} ->어떻게 구분하지? 🔘 회원 수정 / members/{id} ->어떻..