My goal is to implement a generically extendible .NET core web API. The generic refers to modules that can be added at runtime and provide new endpoints as well as functionality. These modules will be developed based on a framework.
Currently I am still deciding if the modules will be included as a DLL or run as a separate process (.exe).
I have the basic understanding of Dependenci Injection regarding the addressing of controllers in a DLL. But now I wonder if and how to realize the whole thing via an own process.
The API should always be addressable via http://localhost/myapi/{endpoint}, i.e. a request to a module should be done via the same URL. For the user / developer of the frontend everything should be presented as one API.
Unfortunately I was not successful on my research and don't know exactly what I have to / should look for specifically. Therefore I hope that you can help me.
Examples are helpful, but I am also keywords or articles, which deal with such a topic, help me further.
kind regards
Related
I want to know if web development can be done using Raku or Perl6?
Like Django for Python, do we have any framework available for Raku?
Id appreciate if you told us which are the libraries available or any tutorial.
Are there any webhosting providers to host Raku web application?
Many folks are using Cro for this. It's a set of libraries that you can pick as needed (and not just for web development), but offers things like:
Routing requests to handlers, and neat ways to express those handlers
WebSocket support integrated neatly into the router
Templating
Testing
There's a simple tutorial as well as a much longer one on making a SPA.
There is also a fresh CRUD server-side tutorial available.
Finally, there's integrated support in the Comma IDE, which includes a Cro project template where you can select the bits you need, indexing of and navigation to routes, and a timeline view that can be used to understand where time is spent during request processing.
There are base images available to support Docker deployment also, to anywhere that supports that.
I built a web framework for Raku called Humming-Bird it's brand new so there are still kinks to work out, but the core works really well! It is intended to be very similar to Sinatra and other frameworks of that style (express.js etc..)
Humming-Bird has most of the typical features of a web framework including but not limited to:
Routing
Middleware
Serving static files
This project is still in fairly early stages, but it offers more than enough to spin up simple web services, and web apps.
First off, I need to mention that I'm not sure if what I'm trying to achieve is even supported by Piranha CMS (that's partly what I'm trying to determine here). They mention the ability to create a standalone content hub on their website, but my assumptions of what is possible with that model might be incorrect. What I've already done is created an ASP.NET MVC application that is hosting Piranha CMS and I've published it to Azure websites for testing purposes--that part works as expected. The content management interface is the only user facing piece here--it is meant only to serve as the content hub for the client application (just the one for now as this is just proof of concept work).
I am now trying to build a client ASP.NET MVC application that pulls content from the hub. This is where I'm thinking that my assumptions may have been wrong. I was thinking that I'd be able to install the Piranha CMS nuget package(s) on the client as well, and I'd be able to configure the framework to get content from the hub in the same way that it would if the content were hosted on the client site. I realize that I could get the content from the hub using Piranha's REST api, but what I want to do is to be able to use the more friendly entity model based api for this.
So my question is whether it is possible (within reason) to setup Piranha CMS in the way that I've described. If it is, how exactly do I configure the client such that it is aware of the location of the content hub?
There are currently no .net client api consuming the rest services as the simplest scenario would be to deploy .net applications together with the server. In the setups I've done native apps & html5 knockout/angular applications have used the rest api's for getting json data. You should however be able to white such a module, performing the HTTP calls and the deserializing the json without any problems.
Regards
HÃ¥kan
Have done a lot of search and reading over the WEB but could not come to any conclusion yet.
We are planning to develop a list of API's (planning to use ASP.NET WEB API). One of the business goals is to package the API and selling/licensing the Packages/API to end users.
Some thoughts that came to consideration:
Using Authorisation Filters to do check against database, if the user requesting the API has access to it or not. Not very sure of the implementation details yet even on this approach.
Are there any better suggestions or ideas or any open source libraries that we can go with?
What are the possible recommendation or best practices to achieve this.
Thanks in advance.
Please take a look at the following links. Hopefully, they help.
Web API creating API keys
How to secure an ASP.NET Web API
I am developing a application that is using backbone.js for most of the front end logic and was thinking of using sqlite for storage, but i have run into a few complications with it and need to switch to another NoSQL database.
I see on ravendb's site that it was created in C# and you need a .net compiler. Most of the docs are for ASP MVC type application. I can not go this root because we are developing this as a tablet application with no microsoft based technologies on the client side ( because we want it to work with android and apple )
The server however will be .NET and so i figured this might be do able. Just wondering if this is worth pursuing and if anyone has had any experience using ravendb? Or should i go for mongodb?
It is possible to expose RavenDB directly to a JavaScript application, sure. But it's usually not recommended. The main reason is security, but there are many other reasons to have a middle-layer.
For example, you often need a server-side location to perform application logic. Not everything can be done in the database itself, and if you do it all in the application then you will probably send a lot more data to the app than it really needs. Over the internet, that could mean a slow app.
The route many people take, is to use ASP.Net WebAPI, or ServiceStack, or another similar framework. This gives you a way to expose REST endpoints that your JavaScript app can call. You can connect to RavenDB from there.
Also, you seem to have the misconception that if you used ASP.Net MVC on the server that you couldn't target Apple or Android. That's just false. Whether you use a SPA approach or a traditional approach, you are delivering standards-based content, such as HTML, CSS, JSON and JavaScript.
Yes, You can use it. Actually RavenDB's server is a RESTful web service, which means you can work with it with any kinds of HTTP clients. These clients should be able to issue standard HTTP verbs like GET, PUT, DELETE etc.
ASP MVC is server side. I still at a loss as to why you would want to expose your db to a clientside piece. It is completely worth doing in a server side piece, but do not expose something like a db directly to your client.
I have a requirement to access a wcf webservice from my node server.I came across a module called wcf.js which was rated for that purpose.But am confused with the part of message can anyone give me an explanation as how to code using that module will be really helpful.
The codeproject article at http://www.codeproject.com/Articles/379389/Wcf-js-Call-WCF-web-services-from-Node-js has some examples of how to call a WCF service using that package. And the project's page on GitHub also has some documentation.
In the GitHub project you can also find some examples, and the tests for this project (and for any project, in general) are always a good starting point to see how one would use a framework.