I am writing a program that will be used to pull data from two separate SaaS softwares via their REST APIs - concatenate them, and save the output as raw JSON. When this is complete - the program will be scheduled to run every night.
The overall concept isn't really complicated, it follows a very simple process:
Pull data from Software A via REST
Pull data from Software B via REST
Concatenate them
Save output as raw JSON
I started off by trying to develop this as a .NET Core Console Application. Mostly straightforward - just using appropriate libraries to send/receive HTTP requests to both software APIs, pulling data, and using IO library to save to JSON file.
However - I've been told that this actually needs to be a web service, not a console application. I have basic experience and knowledge regarding web services, but I need some help understanding how to lay out the entire solution from a high-level.
I think I'm getting confused at understanding how exactly web services work and how my original solution would fit into a web service? And how would my final solution be "deployed" and scheduled to run?
How would I structure the 4 step process above if I were to convert my console application to a web service?
Related
My web application reads and writes data to indexeddb, but at the end of the day, I want to read the data from indexeddb using a Windows Service, which is essentially a C# application. Then from the Windows Service, I want to read the data and want to send the data to a webserver some where.
Browser will not help in that case, because we are taking a scenario where user drops some data and shuts down the browser.
Any help is appreciated!
The standard packaging for .NET libraries is NuGet. If you search nuget.org, you'll see there are a number of packages for indexeddb. I'm not familiar with Indexeddb specifically, but this should give you a good starting point.
I'm building an ECM project, my client wants web and desktop clients. So I decided to build ASP.NET MVC WebApp and WPF desktop client. Both are going to comunicate with business through an Web API project (actually I'm not sure about using Web API or WCF with MTOM as a Service Layer).
Since I expect the project to somehow scale, I'm worried about memory consumption, then I searched and couldn't figure out whether the server is going to use twice the memory when storing/retrieving files.
Suppose some user uploads a 500MB file. MVC receives the file (therefore occupying 500MB of memory for that file, at least I think it's how it works). Assuming the MVC will delegate the request to Web API (which is hosted in the same server), which is going to take care of storing the file, my question is:
Will the server consumes twice the memory during this process?
If yes, are there any techniques to avoid this? (no need to write full examples, I can search for it once I know what to search for).
Feel free to tell me if this is a bad design and suggest different approaches for this scenario, I'm trying to figure out if it's worth separating API in different project.
I have a phonegap iOS app which has a form that, when submitted, it should post some json data to a server and get a response. I have to use C# on the server side and listen somehow when the json is posted from the form in the phonegap app, do some stuff with the data and then respond to the phonegap app. How can I implement the c# server and how should I post the data from my html form? I am experienced in c# desktop applications, but I am really new to everything related to web stuff. The ios app is running in an iphone simulator on a mac in my local network. I have searched for resources but I haven't been able to do this and have been trying for a while. I think I don't need the whole code, just advice on how to do it and what to use.
Any help will be greatly appreciated.
Thanks.
ASP.NET Web Api is exactly what you need. It's a framework for creating web APIs that receive and respond to requests coming through the web, which of course includes JSON data.
ASP.Net MVC and/or ASP.Net WebAPI are perfect for this. Check out the resources at http://asp.net.
The MS Web API won't help with writing a server.
You don't need to write your own server, but you can if you so choose.
Setup and run IIS.
Make a simple ASP.NET Web Forms application
Handle the Page_Load event
Read the value of your json from the posted data using Request.Form["json"]; or whatever you called your posted fields.
System.Web.Script.Serialization.JavaScriptSerializer will help to deserialize your json. Just make a class for your types. You'll have add a reference to System.Web.Extensions.
Publish your application to IIS.
I can highly recommend ServiceStack. It's highly testable, easy to host, and in my experience magnitudes faster than any of the MS web service platforms. Plus, as you don't state what platform your server is, ServiceStack can be hosted on both Windows and Linux systems.
https://github.com/ServiceStack/ServiceStack/wiki/Mono
https://github.com/ServiceStack/ServiceStack/wiki/Self-hosting
Is it possible to create a C# EXE or Windows Service that can process Web Service requests? Obviously, some sort of embedded, probably limited, web server would have to be part of the EXE/service. The EXE/service would not have to rely on IIS being installed. Preferably, the embedded web service could handle HTTPS/SSL type connections.
The scenario is this: customer wants to install a small agent (a windows service) on their corporate machines. The agent would have two primary tasks: 1) monitor the system over time and gather certain pieces of data and 2) respond to web service requests (SOAP -v- REST is still be haggled about) for data gathering or system change purposes. The customer likes the idea of web service APIs so that any number of clients (in any language) can be written to tap into the various agents running on the corporate machines. They want the installation to be relatively painless (install .NET, some assemblies, a service, modify the Windows firewall, start the service) without requiring IIS to be installed and configured.
I know that I can do this with Delphi. But the customer would prefer to have this done in C# if possible.
Any suggestions?
Yes, it's possible, you may want to have a look at WCF and Self Hosting.
Yes, it is possible (and fairly easy).
Here is a CodeProject article showing how to make a basic HTTP server in C#. This could easily be put in a standalone EXE or service, and used as a web service.
One technology you might want to check out is WCF. WCF can be a bit of a pain to get into but there's a great screencast over at DNRTV by Keith Elder that shows how to get started with WCF in a very simple fashion.
http://www.dnrtv.com/default.aspx?showNum=135
You could take a look at HttpListener in the .Net framework.
I would highly recommend WCF. It would fit very well into a product like you are describing. There are a good number of books available.
Sure, you can do that. Be sure to change the Output Type of the project to Console Application. Then, in your Main function, add a string[] parameter. Off of some switch that you receive on the command line, you can branch to ServiceBase.Run to run as a Windows Service or branch to some other code to run a console application.
This question is somewhat older but since I needed something similar some time ago it felt like this question is still relevant.
I wrote a small Rest-API with NancyFx and OWIN. OWIN is a standard interface between .Net applications and web servers. With OWIN it is possible to create a self-hosted WEB-API. Nancy on the other hand is
a lightweight, low-ceremony, framework for building HTTP based
services on .NET ยน
The combination of those two makes it possible to create a self-hosted C# Web service.
I am quite sure that there are many more possibilities to create something like this by now but since I used it like this I thought the Information might be useful to someone.
I am building an app that allows users to execute some commands on a computer by sending them through email. The server will monitor (pull) one or more email accounts and start a communication session. Some authentication is also involved. I am using the latest and greatest .net technologies.
I am thinking to expose the server as a service but then I cannot have a GUI to allow the user to configure things like passwords and email accounts. How can I separate these?
And second, the commands will be pluginable and should provide their own GUI. How can I incorporate this? The server process should be able to use the command functionality and the GUI process should allow for customization.
I have used WCF, which is Microsoft's current technology for implementing web services and/or SOA. You would create a desktop client or webpage that makes calls to the WCF service. The WCF service(s) would be your server component, and the desktop client or webpage would be your user frontend.
It's mainly not a question of how to make service itself. And communication protocol is not the main issue -- with WCF you can expose your application methods via spectre of protocols. It's merely a question of application configuration.
Main question here is how do you like to implement GUI. If your application is normal windows service, then it can't have built-in GUI. Just because service should not have it. So you'll need separate GUI application. Options:
GUI is standalone .NET application that somehow communicates with your service. Let's say via WCF. In this case plugins should also be implemented in two parts: plugin for service and plugin for GUI. I think, it would be too complex to support.
Modification of 1st variant. Both service and GUI are packed in one executable. It looks in what mode it's started (service or standalone) and either monitors mail or shows GUI. Since this is one application, the configuration is also the same. So you will have single registry for plugins. I assume, that in GUI mode application will search for started service and configure it. Drawback - GUI could be run only locally.
You make a sort of "transferrable" GUI - service sends GUI to simple client, which shows it. In this case you have one place for all app code (service and GUI), but it's executed in part in service, in part in client software. But you also need such universal client software.
Thinking a little more about variant 3 we see that solution already exists - it is web technologies. It would be simplest to implement your service as part a web site. And GUI would be another part. If you are unfamiliar with HTML and Javascript you can implement GUI using Silverlight.
In fact, you can host ASP.NET right in your service. Here is the good explanation. But I afraid it adds unnecessary complexity