CODEWITHSUNDEEP
api.net-core
Lennart Hammarström
Lennart Hammarström

Reputation: 477

Should I have views in a .NET Core API

At the company I work at we have a couple of different services

I was asked to create some views which will be converted to PDF's by an API, but I can't decide where to put them as they are not related to our Internal- or External-facing projects.

My first thought was to put them in our .NET Core API. However this has previously been a strict json-only API, so I have an itch that this is not the intended use.

So internet, my questions are as follows

Thanks in advance!

Upvotes: 0

Views: 50

Answers (1)

yesenin
yesenin

Reputation: 199

You're right, Razor views will be excess. I see two options:

  1. Backend: Create an endpoint which will return a PDF file based on passed data. Of course you can expand data. This way is similar with Razor: you have a view model and render it to PDF file. An example of library: iTextSharp.LGPLv2.Core

  2. Frontend: Convert HTML to PDF on client's side. Something like react-pdf

I prefer first option, because, first of all, there is already an option "Save as PDF" in browsers, so it will be some kind of duplication of functionality. And on the other hand back-end PDF generation seems more flexible (you can use all of your domain and you can create independent layout either) and you can organise some kind of file cache.

Upvotes: 1

Related Questions