internal API
I need the same concept as a web API, but it should not be accessible to other applications. Is using a web API still a good idea or what can I use?
14 Replies
How do you define the boundrary between internal and external in this case?
That sounds like a problem to be solved on the network boundary / permission level
"other applications" could also mean applications running locally on the host. We do not know for now
Yeah needs more details on what should be able to access the API and what shouldnt
and what purpose it serves
i have different class libraries that should communicate to each other but i don't want project reference between them, if a class library needs information from another is can access it by the API and handle the response the problem here it will always has to send http requests.
That seems really backwards tbh.
i was looking to mediatr but it i come to the same problem is you have to reference libraries to each other
Having to run an entire webserver just so you can avoid a project reference...
i try to make a modular monolith where each module have their own frontend an backend, but not every instance of the application will have all the modules this will break the references
If you have a modular monolith, it would still be a single combined application, so what would be so bad about sharing a "contract" assembly? When you go the other route of sharing data via IPC, your modular monolith turns into a distributed application with all the drawbacks
that sounds like a locally distributed monolith :d
If you go the IPC route you also need to make sure every participant is familiar with message contracts for request and response types, and if you don't want to share a common definition assembly, you will also run into versioning problems
XD ok i get it, maybe is should indeed go for mediatr instead and accept the reference between the different class libraries
Client Credential Flow