Linux handles interrupts by pointing each IDT descriptor to a bit of common code that sequentially executes a list of interrupt service routines until one of them handles the interrupt. This is needed because of things like IRQ sharing, where multiple devices are on a single IRQ and you don't know which one.
When you register a driver function to be called when some interrupt occurs using request_irq(irq, &driver_function, ...), you're not actually changing the entry in the IDT. But rather the address of your function is put into a new irqaction descriptor, which is added to a chain of other irqaction descriptors, which are then serially executed by the kernel when the interrupt occurs, until one of them returns that it was able to handle the interrupt.
So the term "Interrupt Service Routine" refers to these functions that are executed one by one when an interrupt happens. When you register a driver function to run when an interrupt occurs, you're actually registering it as an Interrupt Service Routine for a vector. There can be many ISRs for any vector.
The term "Interrupt handler" refers to the block of common code in the Linux kernel that is actually pointed to by the IDT that actually executes all of your ISRs one by one. It can also refer to the entire set of code that is executed when an interrupt occurs, and ISRs are elements of that set. From the instruction pointed to by the IDT descriptor, to the final iret instruction, including any ISRs that were or can be executed. But the key takeaway is that there is only one interrupt handler per vector.
The confusion is because "interrupt handler" is a very general term, while "Interrupt Service Routine" refers to something more specific in the Linux context. Outside of this context, they are frequently interchanged and considered to mean the same thing.
I've read the book you're citing, and this is how the book is using these terms.