API with NestJS #114. Modifying data using PUT and PATCH methods with Prisma

June 26, 2023

This entry is part 114 of 180 in the API with NestJS

Developing a REST API requires us to create endpoints using various HTTP methods such as GET, POST, and DELETE. People utilizing our API expect that making a GET request lists data instead of deleting it. It’s the developer’s role to ensure that the API is easy to understand and follows the best practices. While most HTTP methods are straightforward, we can use either POST or the PATCH method to modify existing data. In this article, we learn how to use both of them and outline their differences.

PUT

In the previous parts of this series, we’ve defined a model of a post.

postSchema.prisma

model Post {

id Int @id @default(autoincrement())

title String

paragraphs String[]

author User @relation(fields: [authorId], references: [id])

authorId Int

categories Category[]

scheduledDate DateTime? @db.Timestamptz

@@index([authorId])

}

It has a few required properties and the optional scheduledDate. First, let’s take a look at one of the existing posts.

1	GET /posts/1

Response:

{

"id": 1,

"title": "Hello world!",

"paragraphs": [

"Lorem ipsum"

"authorId": 1,

"scheduledDate": "2023-07-13T10:00:00.000Z"

}

One way of modifying existing posts would be by using a PUT method. It changes existing entities by replacing them. Therefore, if the request does not contain a particular field, the field should be removed.

1	PUT /posts/1

Request body:

{

"id": 1,

"title": "The first article",

"paragraphs": [

"Lorem ipsum"

"authorId": 1

}

Response:

{

"id": 1,

"title": "Hello world!",

"paragraphs": [

"Lorem ipsum"

"authorId": 1,

"scheduledDate": null

}

Since our request body does not contain the scheduledDate property, it should be set to null.

Implementing the PUT method with Prisma

The update method is the most straightforward way to modify an entity using Prisma.

this.prismaService.post.update({

data: {

id: 1,

title: 'The first article',

paragraphs: [

'Lorem ipsum'

authorId: 1

where: {

id: 1,

});

The most important thing about the update method is that it only affects the properties provided explicitly. This means that to remove the scheduledDate property, we need to mark it as null explicitly.

this.prismaService.post.update({

data: {

id: 1,

title: 'The first article',

paragraphs: [

'Lorem ipsum'

authorId: 1,

scheduledDate: null,

where: {

id: 1,

});

To deal with this problem, we can create a Data Transfer Object that assigns null as a default value.

replacePost.dto.ts

import {IsString, IsNotEmpty, IsNumber, IsOptional, IsISO8601} from 'class-validator';

export class ReplacePostDto {

@IsNumber()

id: number;

@IsString()

@IsNotEmpty()

title: string;

@IsString({ each: true })

@IsNotEmpty()

paragraphs: string[];

@IsISO8601({

strict: true,

})

@IsOptional()

scheduledDate: string | null = null;

}

It is worth noting that we use the @IsOptional() decorator above that allows scheduledDate to be undefined, or null.

We can now use the above DTO in our service. To prevent Prisma from modifying the id of existing posts, we can provide undefined as the id.

posts.service.ts

import { Injectable } from '@nestjs/common';

import { PrismaService } from '../prisma/prisma.service';

import { Prisma } from '@prisma/client';

import { PrismaError } from '../utils/prismaError';

import { PostNotFoundException } from './exceptions/postNotFound.exception';

import { ReplacePostDto } from './dto/replacePost.dto';

@Injectable()

export class PostsService {

constructor(private readonly prismaService: PrismaService) {}

async replacePost(id: number, post: ReplacePostDto) {

try {

return await this.prismaService.post.update({

data: {

...post,

id: undefined,

where: {

id,

});

} catch (error) {

if (

error instanceof Prisma.PrismaClientKnownRequestError &&

error.code === PrismaError.RecordDoesNotExist

) {

throw new PostNotFoundException(id);

}

throw error;

}

// ...

}

An important thing above is that we are using the PrismaError enum we created in some of the previous parts of this series. It helps us understand the error that happened and allows us to act accordingly.

prismaError.ts

export enum PrismaError {

RecordDoesNotExist = 'P2025',

UniqueConstraintFailed = 'P2002',

}

The last step is to add a PUT method handler to our controller.

posts.controller.ts

import {

Body,

Controller,

Param,

Put,

} from '@nestjs/common';

import { PostsService } from './posts.service';

import { FindOneParams } from '../utils/findOneParams';

import { ReplacePostDto } from './dto/replacePost.dto';

@Controller('posts')

export default class PostsController {

constructor(private readonly postsService: PostsService) {}

@Put(':id')

async replacePost(

@Param() { id }: FindOneParams,

@Body() post: ReplacePostDto,

) {

return this.postsService.replacePost(id, post);

}

// ...

}

Thanks to using our DTO, if the users make a PUT request without providing the scheduledDate, we change it to null.

PATCH

Another approach to modifying existing entities is through a PATCH method. The HTTP protocol describes it as modifying an entity partially through a set of instructions. The most straightforward way of implementing it is by sending a request body with the partial entity.

1	PATCH /posts/1

Request body:

{

"id": 1,

"title": "The first article",

"paragraphs": [

"Lorem ipsum"

"authorId": 1

}

Response:

{

"id": 1,

"title": "The first article",

"paragraphs": [

"Lorem ipsum"

"authorId": 1,

"scheduledDate": "2023-07-13T10:00:00.000Z"

}

The crucial thing about the above request is that we don’t provide the scheduledDate property when modifying our post. To delete a property, we need to send null explicitly. Thanks to that, we can avoid removing values by accident.

Implementing the PATCH method with Prisma

Let’s start by creating a new Data Transfer Object for the PATCH method. Since with sending a PATCH request, all properties are optional, we might think of using the @IsOptional() decorator.

updatePost.dto.ts

import {

IsString,

IsNotEmpty,

IsNumber,

IsISO8601,

IsOptional,

} from 'class-validator';

export class UpdatePostDto {

@IsNumber()

@IsOptional()

id?: number;

@IsString()

@IsNotEmpty()

@IsOptional()

title?: string;

@IsString({ each: true })

@IsNotEmpty()

@IsOptional()

paragraphs?: string[];

@IsISO8601({

strict: true,

})

@IsOptional()

scheduledDate?: string | null;

}

However, there is one big issue with it. Unfortunately, it causes the class-validator to allow both undefined and null as the value for the decorated property. This can cause an Internal server error in our application because most of our columns are not nullable. We can solve this problem by using the ValidateIf decorator.

updatePost.dto.ts

import {

IsString,

IsNotEmpty,

IsNumber,

IsISO8601,

ValidateIf,

} from 'class-validator';

export class UpdatePostDto {

@IsNumber()

@ValidateIf((object, value) => value !== undefined)

id?: number;

@IsString()

@IsNotEmpty()

@ValidateIf((object, value) => value !== undefined)

title?: string;

@IsString({ each: true })

@IsNotEmpty()

@ValidateIf((object, value) => value !== undefined)

paragraphs?: string[];

@IsISO8601({

strict: true,

})

@ValidateIf((object, value) => value !== undefined && value !== null)

scheduledDate?: string | null;

}

With the above code, we validate the properties only if they match the provided condition. We can simplify our DTO a lot by creating two custom decorators that use ValidateIf() under the hood.

canBeNull.ts

import { ValidateIf } from 'class-validator';

export function CanBeNull() {

return ValidateIf((object, value) => value !== null);

}

canBeUndefined.ts

import { ValidateIf } from 'class-validator';

export function CanBeUndefined() {

return ValidateIf((object, value) => value !== undefined);

}

Thanks to our new decorators, our code can be cleaner and shorter.

updatePost.dto.ts

import { IsString, IsNotEmpty, IsNumber, IsISO8601 } from 'class-validator';

import { CanBeUndefined } from '../../utils/canBeUndefined';

import { CanBeNull } from '../../utils/canBeNull';

export class UpdatePostDto {

@IsNumber()

@CanBeUndefined()

id?: number;

@IsString()

@IsNotEmpty()

@CanBeUndefined()

title?: string;

@IsString({ each: true })

@IsNotEmpty()

@CanBeUndefined()

paragraphs?: string[];

@IsISO8601({

strict: true,

})

@CanBeUndefined()

@CanBeNull()

scheduledDate?: string | null;

}

Implementing the PATCH method with Prisma is very straightforward, thanks to how the update method works. It modifies only the explicitly provided properties, which is precisely what we need.

posts.service.ts

import { Injectable } from '@nestjs/common';

import { PrismaService } from '../prisma/prisma.service';

import { UpdatePostDto } from './dto/updatePost.dto';

import { Prisma } from '@prisma/client';

import { PrismaError } from '../utils/prismaError';

import { PostNotFoundException } from './exceptions/postNotFound.exception';

@Injectable()

export class PostsService {

constructor(private readonly prismaService: PrismaService) {}

async updatePost(id: number, post: UpdatePostDto) {

try {

return await this.prismaService.post.update({

data: {

...post,

id: undefined,

where: {

id,

});

} catch (error) {

if (

error instanceof Prisma.PrismaClientKnownRequestError &&

error.code === PrismaError.RecordDoesNotExist

) {

throw new PostNotFoundException(id);

}

throw error;

}

// ...

}

Finally, we need to add the PUT method handler to our controller.

posts.controller.ts

import { Body, Controller, Param, Put } from '@nestjs/common';

import { PostsService } from './posts.service';

import { FindOneParams } from '../utils/findOneParams';

import { ReplacePostDto } from './dto/replacePost.dto';

@Controller('posts')

export default class PostsController {

constructor(private readonly postsService: PostsService) {}

@Put(':id')

async replacePost(

@Param() { id }: FindOneParams,

@Body() post: ReplacePostDto,

) {

return this.postsService.replacePost(id, post);

}

// ...

}

Thanks to all of the above, we can now support a PUT method.

Summary

Both the PUT and PATCH method have their use cases and can be useful. However, with the PATCH method, we don’t expect the user to know about all of the properties of our entity. Since deleting a value requires the users to provide null explicitly, it is less likely that they will remove a property by accident.

Since, in this article, we’ve gone through both PUT and PATCH and implemented them in our application with NestJS in Prisma, you now have the necessary knowledge to use the approach that suits your project the most.

Series Navigation<< API with NestJS #113. Logging with PrismaAPI with NestJS #115. Database migrations with Prisma >>