Postman을 이용하여 CRUD 테스트해보기

interface

ts의 타입을 결정하는 interface 같은 경우 두 가지 생각을 해봤다. 모듈마다 interface를 설정하기 vs interfaces directory를 만들고 여기서 모든 interface를 관리하기 서비스마다 다르겠지만, 현재 나는 공부하는 입장에서 interface를 모듈 내에 넣는걸 채택하였다. 먼저 모듈 내에 넣으면 직관적이다. 이 모듈 내에서 사용하는 interface는 이거구나 라는 사실을 한눈에 알 수 있다. 단점이라고 하면 재사용하기가 조금 불편할 수 있다. 난 근데 그냥 모듈 내에 interface를 넣을래요. 근데 지금 보니깐 interfaces, types directory를 새로 하는 게 낫겠다.

POST Method

@Body() 데코레이터를 이용하여 body에 담겨진 data를 불러오고 service로 전달함.

// controller post
 @Post()
  create(@Body() createTodoDto: CreateTodoDto) {
    return this.todosService.create(createTodoDto);
  }

서비스 클래스 내에서 todo를 담을 배열 todos을 하나 선언하고, todo가 생성될 때마다 배열 todos에 push하게 하기 이때 고유 id로 Date.now()를 호출하여 할당하기

// service post
create(createTodoDto: CreateTodoDto):string {
    const newTodo = {
      id: Date.now(),
      ...createTodoDto,
    };

    this.todos.push(newTodo);
    return `${newTodo.id} ${newTodo.todo}`;
  }

여기서는 date.now()를 이용하여 고유 id를 할당해줬지만, UUID라는 라이브러리가 존재한다. UUID를 불러오면 고유 id를 할당 할 수 있다. 중복되는 일이 없음

GET Method

get에서는 두가지를 구현해보았다. 전체 post를 보내는 get method findAll / params로 id를 전달해주면 해당 id를 뽑아서 todo를 전해주는 get method findOne

// controller get
  @Get()
    findAll() {
      return this.todosService.findAll();
    }

  @Get(':id')
  findOne(@Param('id') id: string) {
    // id를 +id로 넘기는 이유
    // params로 받으면 현재 id는 string이다
    // 우리가 필요한 건 Number이므로 
    // + 연산자를 이용하여 형변환을 진행 (string -> number)
    return this.todosService.findOne(+id);
  }

// service get
  findAll(): todo[] {
    return this.todos;
  }

  findOne(id: number): todo | string {
    const findTodo = this.todos.find((todo) => todo.id === id);

    return findTodo ? findTodo : 'error';
  }

PATCH Method

PATCH vs PUT

특징	PUT	PATCH
목적	전체 리소스를 대체	리소스의 일부를 수정
요청 데이터	리소스의 전체 표현이 필요	변경하려는 필드만 필요
기존 필드 처리	포함되지 않은 필드는 기본값 또는 null로 설정	포함되지 않은 필드는 그대로 유지
멱등성(Idempotency)	멱등성 있음	멱등성 있을 수도 있고 없을 수도 있음
사용 예시	사용자 전체 정보 업데이트	사용자 이메일 주소만 업데이트

즉, PUT은 전체 리소스를 업데이트할 때, PATCH는 리소스의 일부만 업데이트할 때 사용한다.

지금까지 @Param()를 사용했기 때문에, @Query() 데코레이터인 쿼리스트링을 사용해보기로 했다. 공부하는 거니깐 !!! param 대신 query를 사용한 겁니다. 업데이트 경우 param를 이용하여 업데이트 하는 걸로 알고 있습니다.

// controller Patch
@Patch()
  update(@Query('id') id: string, @Body() updateTodoDto: UpdateTodoDto) {
    return this.todosService.update(+id, updateTodoDto);
  }

// service Patch
update(id: number, updateTodoDto: UpdateTodoDto): todo[] | string {
    const findTodo = this.todos.find((todo) => todo.id === id);

    findTodo.todo = updateTodoDto.todo;

    return findTodo ? this.todos : 'error';
  }

Query String vs Params

차이점	Query String	Params (경로 매개변수)
목적	리소스의 동작 수정, 필터링, 검색, 정렬 등	특정 리소스를 식별
위치	URL의 끝에 ?로 시작, 여러 파라미터는 &로 구분	URL 경로의 일부로 사용
형식	?key=value&key2=value2	/resource/:id
사용 사례	GET /users?name=John&age=25 (검색 조건)	GET /users/1 (특정 리소스 조회)
전달 데이터 수	여러 개의 파라미터를 전달할 수 있음	일반적으로 하나 또는 소수의 리소스 식별자 사용
중복 가능성	같은 파라미터를 여러 번 전달 가능 (?name=John&name=Jane)	경로에서 중복된 식별자는 논리적으로 의미가 없음
SEO 영향	검색 엔진이 파라미터로 구분된 URL을 다른 페이지로 인식할 수 있음	경로 기반의 URL은 더 직관적이고 SEO에 유리
표준화된 사용 방법	자원의 상태를 변경하지 않음	RESTful한 API 설계에서 자원의 CRUD 작업을 나타냄

DELETE Method

id를 params로 넘겨주고 filter를 걸어서 삭제하기 이후 return을 todos 전부 리턴해주기

// controller delete
@Delete(':id')
  remove(@Param('id') id: string) {
    return this.todosService.remove(+id);
  }

// service delete
  remove(id: number): Todo[] {
    this.todos = this.todos.filter((todo) => todo.id !== id);

    return this.todos;
  }