SEOB_TECH SEOB_TECH

-오랜만에 쓰는 개발 공부 글.. Docker Image - Docker Container를 구성하는 File System과 실행할 Application 설정을 하나로 합친 것, Container를 생성하는 Template역할을 한다. Docker Container - Docker Image를 기반으로 생성되며, File Systemrhk Application이 구체화 되어 실행되는 상태를 의미. Docker Image 한개로 여러 개의 컨테이너를 생성할 수 있음. Docker Instruction - FROM Docker Image의 바탕이될 베이스 Image를 지정한다. Dockerfile로 Image를 Build할 때 먼저 FROM 인스트럭션에 지정된 이미지를 내려 받는다. FROM에서 받아오는 D..

5xx (Server Error) 서버 오류 서버 문제로 오류 발생 서버에 문제가 있기 때문에 재시도시 성공할 수도 있음 500 Internal Server Error 서버 문제로 오류 발생, 애매하면 500 Error 서버 내부 문제로 오류 발생. 애매하면 500 503 Service Unavailable 서비스 이용 불가 서버가 일시적 과부하 혹은 예정된 작업으로 요청을 처리할 수 없는 경우 Retry-After Header Field로 얼마뒤 복구되는지 보낼 수도 있음

4xx (Client Error) 클라이언트 오류 클라이언트 요청에 잘못된 문법등으로 서버가 요청을 수행할 수 없음 요청 구문, 메시지 등등 오류 클라이언트는 요청 내용을 다시 검토하고 보내야 한다. ex) 요청 parameter error or API spec에 맞지 않을 때 401 Unauthorized 클라이언트가 해당 리소스에 대해 인증이 필요할 때 인증이 되지 않은 상태 401 error 발생시 응답에 WWW-Authenticate Header와 함께 인증 방법 설명 Authentication(인증) 본인이 누군지 확인하는 과정 (로그인) Authorization(인가) 권한부여 (Admin 처럼 특정 리소스에 대한 접근 권한이 있는 경우 인증이 있어야 인가가 있음) Error Message가 ..

3xx Redirection 요청을 완료하기 위해 유저의 추가적 조치가 필요한 상황 웹 브라우저는 3xx 응답의 결과에 location header 가 존재 시 해당 location으로 이동하며 이를 redirect라 한다. 영구 redirection - 특정 리소스가 영구적으로 이동하는 케이스 원래의 url을 사용하지 않는다. 검색엔진 등에서도 변경을 인지한다. 301 moved permanently 리다이렉트시 요청 메서드가 get으로 변하고 본문 제거 될 수도 있음 (MAY) 308 permanent redirect 301과 기능은 같으나 리다이렉트 요청시 메서드와 본문 유지 (Post -> Post) 실무에선 POST로 와도 GET으로 돌림 (308 잘안씀 301 쓴다) Ex) /members -..

클라이언트에서 서버로 데이터 전송할 때 크게 2가지 전달 방식을 사용한다 쿼리 파라미터를 통한 데이터 전송 GET 주로 정렬 필터 (검색어) 메세지 바디를 통한 데이터 전송 POST, PUT, PATCH 회원 가입, 상품 주문, 리소스 등록, 리소스 변경 클라이언트에서 서버로 데이터 전송을 하는 4가지 상황 정적 데이터 조회 쿼리 파라미터 미사용 이미지나 정적 텍스트 문서를 전달. 조회는 GET METHOD를 사용하지만 단순히 리소스 경로를 사용해 조회가 가능하다. 동적 데이터 조회 쿼리 파라미터 사용 서버는 쿼리 파라미터를 기반으로 정렬 필터를 적용해 결과를 동적으로 생성해서 보내준다. 주로 검색, 게시판 목록에서 정렬 필터 (검색어) 조회 조건을 줄여주는 필터, 조회 결과를 정렬하는 정렬 조건에 주로..

PUT PUT /members/100 HTTP/1.1 Content-Type: application/json {"username": "hi", "Age":10} 리소스를 대체한다.(완전히 대체 한다) 리소스가 존재하면 대체하고 없다면 생성한다. 즉 덮어쓰기 클라이언트가 리소스를 식별한다. 클라이언트가 리소스 위치를 알고 URI를 지정한다. 리소스를 완전히 대체하기 때문에 리소스의 필드에 유의해야함, 누락되는 경우 손실되는 필드가 존재한다. PATCH PATCH /members/100 HTTP/1.1 Content-Type: application/json {,"Age":21} 리소스의 부분 변경 PATCH가 지원되지 않는 서버가 존재한다. 이런 경우 POST를 사용하면 된다 (대다수가 지원함) DELETE..

GET GET/search?q=hello&hl=ko HTTP/1.1 HOST: www.google.com 리소스 조회 서버에 전달하고 싶은 데이터의 경우 Query를 사용해 전달 (쿼리 파라미터, 혹은 스트링) 메시지 바디를 사용해 데이터를 전달할 수는 있지만, 지원하지 않는 곳이 많아서 권장하지 않음. ->최근 스펙에선 허용되지만 실무에서는 보통 사용하지 않는다고 한다. HTTP Method를 사용한 리소스 조회 방식 members/100 = { "username" : "hi", "age" : 20 } 1. 메시지 전달 & 서버 도착 GET /members/100 HTTP/1.1 HOST : localhost:8080 2. 메시지 생성 (응답 데이터) HTTP/1.1 200 OK Content-Type..

요구사항 회원 정보 관리 API를 만들어 보자. API URI 설계 (리소스 설계) 회원 목록 조회 회원 조회 회원 등록 회원 수정 회원 삭제 리소스의 의미는? 회원을 등록하고 수정하고 조회하는게 리소스가 아니고, 회원이라는 개념 자체가 리소스다. 리소스를 어떻게 식별하는게 좋을까? 회원을 등록하고 수정하고 조회하는 것을 모두 배제하고 회원이라는 리소스만 식별하면 된다. -> 회원 리소스를 URI에 맵핑. 회원 목록 조회 /members 회원 조회 /members/{id} 회원 등록 /members/{id} 회원 수정 /members/{id} 회원 삭제 /members/{id} → 어떻게 구분할 것인가? → HTTP의 Method를 통해서 구분짓는다. URI는 리소스만 식별할 수 있어야 한다. 리소스와 ..