Linux에서 .NET Aspire에 PUT 업데이트 엔드포인트 추가하기

업데이트 레코드 유형 생성

[1:54 - 4:04] 이전 에피소드의 삽입 레코드는 제목, 설명 및 우선순위를 수락했습니다. 업데이트 레코드는 수정 중인 티켓의 ID와 DateCompleted 타임스탬프, 두 가지 추가 필드가 필요합니다. 팀은 삽입 레코드를 복사하고 조정합니다.

public record TicketUpdateRecord(
    [Required, Range(1, int.MaxValue)] int Id,
    [Required, MinLength(1)] string Title,
    [Required] string Description,
    DateTime? DateCompleted,
    [Range(1, 5)] int Priority
);

public record TicketUpdateRecord(
    [Required, Range(1, int.MaxValue)] int Id,
    [Required, MinLength(1)] string Title,
    [Required] string Description,
    DateTime? DateCompleted,
    [Range(1, 5)] int Priority
);

Id를 [Range(1, int.MaxValue)] 제약조건으로 [Required]로 표시하면 음수값이나 0이 데이터베이스에 도달하는 것을 방지할 수 있습니다. DateCompleted는 null 가능 DateTime?입니다. 아직 해결되지 않은 티켓은 완료 날짜가 필요하지 않기 때문입니다. 유효성 검사 속성은 필요하지 않으며, null이 유효한 상태입니다.

기록 속성이 정확히 일치하는지 확인하기 위해 Tim은 spTickets_Update 저장 프로시저에서 필드 목록을 가져옵니다. 이 정렬로 인해 Dapper가 수동 속성-파라미터 연결 없이 직접 레코드를 매핑할 수 있습니다.

PUT 엔드포인트 매핑

[4:04 - 5:44] 엔드포인트 등록은 설정된 패턴을 따릅니다. MapPut는 /api/tickets 경로에 바인딩되고, 핸들러는 업데이트 기록과 함께 저장 프로시저를 호출합니다:

app.MapPut("/api/tickets", async Task<Results<NoContent, ValidationProblem>>
    (TicketUpdateRecord ticket, ISqlDataAccess sql) =>
{
    await sql.SaveDataAsync("dbo.spTickets_Update", ticket, "TicketDB");
    return TypedResults.NoContent();
});

app.MapPut("/api/tickets", async Task<Results<NoContent, ValidationProblem>>
    (TicketUpdateRecord ticket, ISqlDataAccess sql) =>
{
    await sql.SaveDataAsync("dbo.spTickets_Update", ticket, "TicketDB");
    return TypedResults.NoContent();
});

반환 유형으로 Results<NoContent, ValidationProblem>를 선언하면 성공 시 204를, 유효성 검사 실패 시 400을 생성함을 프레임워크에 알려줍니다. 이전 에피소드에 등록된 파이프라인에 의해 ValidationProblem 변형은 자동으로 처리됩니다; 핸들러 자체는 성공 사례만 반환하면 됩니다.

데이터 액세스를 간결하게 유지하는 Dapper 래퍼의 작동 방식은 저장 프로시저 이름, 모델, 연결 문자열 이름입니다. 세 개의 매개 변수가 전체 데이터베이스 호출을 다룹니다. 래퍼는 시리즈 초기에 작성되었으며, 각 새로운 엔드포인트가 수정 없이 재사용되면서 이점을 계속 제공합니다.

PUT 대 PATCH: 전체 교체가 중요한 경우

[6:06 - 6:46] 테스트 전, 팀은 PUT과 PATCH의 차이를 명확히 하기 위해 잠시 멈춥니다. PUT 요청은 자원의 모든 필드를 대체합니다: 요청 본문의 모든 필드가 호출자가 변경할 의도가 없더라도 해당 데이터베이스 열을 덮어씁니다. PATCH 요청은 본문에 포함된 필드만 업데이트합니다.

Tiny Ticket 프로젝트에서는, 프론트엔드가 전체 티켓을 로드하고 사용자가 필드를 편집할 수 있게 한 후 완료된 개체를 다시 보내는 것이 유효하므로 PUT이 올바른 선택입니다. 프로덕션 애플리케이션에서는 요청된 특정 작업에 대해 PATCH 엔드포인트를 추가할 가능성이 있다고 팀은 언급합니다. 예를 들어, 티켓을 완료로 표시하는 것은 단일 필드를 조작하는 일반적인 작업이므로 전체 개체를 보내기에는 비효율적입니다.

Swagger를 통한 업데이트 테스트

[6:46 - 8:26] Tim launches the API and opens Swagger. PUT을 테스트하기 전에, GET 모든 엔드포인트를 실행하여 데이터의 현재 상태를 확인합니다. 테스트 레코드 중 하나(ID 109)는 이전 테스트에서 제목, 설명 및 우선순위가 비어 있습니다. 업데이트의 대상이 됩니다.

팀은 ID 109, "샘플 레코드" 제목, 설명 및 5의 우선순위로 PUT 요청 본문을 작성합니다. 실행 후 응답은 204로 반환됩니다. GET을 다시 실행하면 레코드가 이제 업데이트된 값을 가지고 있음을 확인합니다.

유효성 검사를 확인하기 위해, 그는 제목 필드를 비우고 다시 실행합니다. 응답은 "티켓 제목 필드는 필수입니다."라는 구조화된 오류 메시지와 함께 400으로 반환됩니다. 삽입 엔드포인트에서 사용한 동일한 주석 패턴이 업데이트 기록으로 이어지므로 동일한 유효성 검사 속성이 적용됩니다.

정리: CRUD 진행 상황

[8:26 - 8:43] PUT 엔드포인트가 완료되면, Tiny Ticket API는 CRUD 작업 중 세 개를 다룹니다: 읽기(GET 모든 및 ID로 GET), 생성(POST), 업데이트(PUT). 각 엔드포인트는 동일한 구조 패턴을 따르므로 코드베이스를 예측할 수 있게 만듭니다. 남은 작업은 DELETE이며, 팀은 다음 에피소드로 미리 보기를 제공합니다.

결론

[8:38 - 8:43] 최소 API에 PUT 엔드포인트를 추가하려면 유효성 검사 속성이 있는 전용 업데이트 기록, 컬렉션 URL과의 MapPut 등록, 데이터 액세스 래퍼를 통한 저장 프로시저 호출이 필요합니다. Results<NoContent, ValidationProblem> 반환 유형은 프레임워크가 성공 및 유효성 검사 실패 응답을 처리할 수 있도록 합니다. DateTime?와 같은 null 가능 필드는 유효성 검사 속성이 필요 없기 때문에 불완전한 데이터에 대한 유효한 값으로 간주되어 그대로 통과됩니다.

시리즈 네비게이션: 이 기사는 Linux에서 Tiny Ticket 앱을 구축하는 C# 시리즈의 일부입니다. 이전: POST 삽입 엔드포인트 추가. 다음: 삭제 엔드포인트 추가.

예시 팁: 업데이트 저장 프로시저가 수정된 행 수를 반환하면, 204를 반환하기 전에 이를 확인하십시오. 0인 경우 ID가 어떤 레코드와도 일치하지 않으며, 404를 반환하는 것이 좋습니다.

전체 비디오를 그의 YouTube 채널에서 보고 C# 시리즈의 Linux에서 CRUD 엔드포인트 구축에 대한 더 많은 통찰력을 얻으세요.