Django에서 View를 만들어 웹 게시판에서 가장 기본 기능인 Create, Read, Update, Delete를 구현해보자. DRF에서 뷰를 만드는 것은 순수 장고를 사용할때와 마찬가지로 함수형, 클래스형 2가지로 나눌 수 있다. REST Framework는 API 뷰를 만드는데 2가지 wrapper를 제공한다. 함수형 View: @api_view 클래스형 View: APIView wrapper에서는 뷰에서 Request 인스턴스를 수신하고, 해당 메소드를 인자로 전달해서 메소드에 맞는 로직 실행. 클래스형 View는 APIView, GenericView, ViewSet으로 추상화 단계를 높일 수 있는데 우선 APIView부터 알아보자. 1. 엔드포인트 구성(urls.py) - pk(primary..
Django Rest Framework DRF를 공부했는데 정리가 필요한 것 같고 직접 간단히 실습하기 위해서 코드를 돌려봤습니다 ! joeylee.log 블로그를 참고하였습니다. Pycharm을 이용해 newapi 프로젝트를 생성하고 python manage.py startapp news 명령어를 이용해 news 어플리케이션을 추가해줍니다 ! 1. news/models.py 작성 class Article(models.Model): #author = models.ForeignKey(Journalist, on_delete=models.CASCADE, related_name="articles") author = models.CharField(max_length=120) title = models.CharFi..
Spring Container 스프링 컨테이너 ApplicationContext를 스프링 컨테이너라 한다. 이전까지는 개발자가 AppConfig를 사용해서 직접 객체를 생성하고 의존관계 주입하는 순수 자바코드만을 사용했다. 지금부터는 스프링 컨테이너를 사용해 개발해보자 ! 스프링 컨테이너란? 스프링 컨테이너는 자바 객체의 생명 주기를 관리하며, 생성된 자바 객체들에게 추가적인 기능을 제공하는 역할을 한다. 여기서 말하는 자바 객체를 스프링에서는 빈(Bean)이라고 부릅니다. 그리고 IoC와 DI의 원리가 이 스프링 컨테이너에 적용됩니다. 스프링 컨테이너는 Class 상단에 @Configuration이 붙은 AppConfig를 구성 정보로 사용한다. Class 내부에 함수들을 선언하기 전에 @Bean으로 ..
DI(Dependency Injection) DI란 스프링이 제공하는 의존 관계 주입 기능으로, 객체를 직접 생성하는 것이 아닌 외부 APP에서 생성한 후 객체를 주입 시켜주는 방식이다. DI를 통해 모듈 간의 결합도(Coupling)이 낮아지고 유연성이 높아진다. 좋은 소프트웨어를 설계하기 위해서는 응집도(Cohesion)는 높아야 하고 결합도(Coupling)은 낮아야 한다. 방법 1은 A 객체가 B와 C객체를 직접 생성자를 통해서 생성하는 방법이고 방법 2는 외부에서 생성된 객체를 setter()나 생성자를 통해 사용하는 방법이다 주문 시스템의 클래스 다이어그램을 살펴보면 문제점을 찾을 수 있다. 할인 정책을 고정 할인 정책에서 비율 할인 정책으로 변경하는 경우 클라이언트 코드인 OrderServi..
Django Rest Framework Django 안에서 RESTful API 서버를 쉽게 구출할 수 있도록 도와주는 오픈소스 라이브러리 웹 브라우저 API는 개발자들에게 유용성을 가져다 준다 Serialize 기능 제공 (DB Data -> JSON) Serialization은 ORM과 non-ORM 데이터 소스를 모두 지원 View를 커스터마이징 해서 사용할 수 있다 관련 도큐먼트가 많다 DRF의 큰 기능은 Models를 serializers로 변환하는 것 - Serializer(직렬화) Serialize: 추상적인 Object를 구체적이고, 저장가능하고, 전송가능한 텍스트 파일로 바꿔주는 것 말 그대로 직렬화하는 클래스로서, 사용자의 DB안에 사용자 프로필 사진, 이메일, 이름, 성별이 있다고 가..
캐시가 없는 경우 서버에 요청이 들어오면 서버에서 헤더와 바디를 만들어 내려준다 데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운 받아야 한다 인터넷 네트워크는 매우 느리고 비싸고, 브라우저 로딩 속도가 느려진다 캐시를 적용하는 경우 브라우저 캐시에 일정 시간동안 저장한 후 다음 접근은 캐시에서 조회하여 요청을 받아온다 -> 네트워크를 사용하지 않음 만약 일정 시간이 초과된 경우 다시 서버로 요청을 보내 응답 받음 -> 캐시를 갱신한다 -> 네트워크 사용 • 캐시 덕분에 캐시 가능 시간동안 네트워크를 사용하지 않아도 된다. • 비싼 네트워크 사용량을 줄일 수 있다. • 브라우저 로딩 속도가 매우 빠르다. • 빠른 사용자 경험 캐시 시간 초과 캐시 유효 시간이 초과해서 서버에 다시 요청하면 다..
HTTP 헤더 개요 • 메시지 본문(message body)을 ,통해 표현 데이터 전달 • 메시지 본분 = 페이로드(payload) • 표현은 요청이나 응답에서 전달할 실제 데이터 • 표현 헤더는 표현 데이터를 해석할 수 있는 정보 제공 • 데이터 유형(html, json), 데이터 길이, 압축 정보 등등 표현 어떤 리소스를 html이라는 표현으로 전달할 것이냐, json형태의 표현으로 전달할 것이냐 • Content-Type: 표현 데이터의 형식 설명 - 미디어 타입, 문자 인코딩 - 예) text/html; charset=uft-8 • Content-Encoding: 표현 데이터 인코딩 - 표현 데이터를 압축하기 위해 사용 - 데이터를 전달하는 곳에서 압축 후 인코딩 헤더 추가 - 데이터를 읽는 쪽에..
상태 코드 클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능 1xx (Informational): 요청이 수신되어 처리 중 2xx (Successful): 요청 정상 처리 3xx (Redirection): 요청을 완료하려면 추가 행동이 필요 4xx (Client Error): 클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수행할 수 없음 5xx (Server Error): 서버 오류, 서버가 정상 요청을 처리하지 못함 만약 모르는 상태 코드가 나타나면 백의 자리 숫자를 보고 판단하면 된다 1xx (Informational): 요청이 수신되어 처리 중 • 거의 사용하지 않음 2xx (Successful): 요청 정상 처리 • 200 OK: 요청 성공 • 201 Created: 요청 성공해서 ..
클라이언트에서 서버로 데이터 전송 정적 데이터 조회 이미지, 정적 텍스트 문서 동적 데이터 조회 주로 검색, 게시판 목록에서 정렬 필터(검색어) HTML Form을 통한 데이터 전송 회원 가입, 상품 주문, 데이터 변경 HTTP API를 통한 데이터 전송 회원 가입, 상품 주문, 데이터 변경 서버 to 서버, 앱 클라이언트, 웹 클라이언트(Ajax) 정적 데이터 조회 이미지, 정적 텍스트 문서 조회는 GET 사용 정적 데이터는 일반적으로 쿼리 파라미터 없이 리소스 경로로 단순하게 조회 가능 동적 데이터 조회 쿼리 파라미터 사용 ex) ?q=hello&hl=ko 쿼리 파라미터를 기반으로 정렬 필터해서 결과를 동적으로 생성 주로 검색, 게시판 목록에서 정렬 필터 조회 조건을 줄여주는 필터, 조회 결과를 정렬..
회원 정보 관리 API 설계 요구사항으로 아래와 같이 주어졌다고 하자 회원 목록 조회 회원 조회 회원 등록 회원 수정 회원 삭제 URI를 설계하는 단계에서 회원 목록 조회 /read-member-list 회원 조회 /read-member-by-id 회원 등록 /create-member 회원 수정 /update-member 회원 삭제 /delete-member 위와 같이 직관적으로 URI를 작성하는 것은 바람직하지 않은 방법이다. 가장 중요한 것은 리소스 식별 ! 그렇다면 리소스란 무엇일까? 회원을 등록하고 수정하고 조회하는 것이 리소스가 아님 회원이라는 개념 자체가 바로 리소스 리소스는 어떻게 식별하는게 좋을까? 회원이라는 리소스만 식별 -> 회원 리소스를 URI에 매핑 회원 목록 조회 /members ..
- Total
- Today
- Yesterday
- ZNS
- 8주차 회고
- 회고
- 알림개선기
- 알림기능개선기
- 런칭 페스티벌
- 스프링 부트
- 우테코
- 스프링 프레임워크
- ZNS SSD
- dm-zoned 코드분석
- 스프링 Logback
- 네트워크
- 백준
- 2차 데모데이
- 프로젝트
- CI/CD
- 환경 별 로깅 전략 분리
- 5주차 회고
- 피움 6주차 회고
- 3차 데모데이
- java
- 파이썬
- jpa
- 스프링MVC
- 피움
- dm-zoned
- Spring
- 팀프로젝트
- 우테코 회고
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |