If i want to develop an iPhone app with a client-server design (iPhone devices as the clients and a c# server),two questions:
Is it possible to use my own laptop to run the server on? and if not what are my options?
Do i have to develop my own protocol for transferring messages?
So if i understood right the process of sending a message like "CREATE NEW USER" from the client to the server is as follow:
1. The client will create a JSON/XML containing the command "CREATE NEW USER" and the new user details.
2. The client will send this JSON/XML via HTTP request (as the body of the HTTP request) with a URL that maps to a c# method on the server side.
3. This will trigger the appropriate method on the server and the new user will be created on the database.
4. The server will create JSON/XML containing the replay "CREATED" and will send it to the client vie HTTP response (as the body of the HTTP response).
Is that correct?
You want either xml or json over http. Web Services and REST over http was created for interoperability problems between different platforms which is what you're facing.
Since you're using C# for the server, you can look into WCF and use either a REST pattern or SOAP (web services) to expose your actions and data. Concerning the data you can serialize those objects over the wire as JSON or XML.
For iPhone consumption, I would recommend REST (since that basically maps a url request path to a C# method). From the phones perspective, it's just a url request and xml or json data comes back.
In C# you simply create your methods and decorate them with DataContract attributes. Then, on your methods you map them to url relative paths. Search the net for WCF and REST services. You can run it in any host from a command line to a windows service to IIS.
http://msdn.microsoft.com/en-us/library/bb412178.aspx
When creating those C# services, if REST, you can hit the requests in a browser and see the data come through. You should also look into Fiddler to inspect your traffic: http://www.fiddler2.com/fiddler2/
On the phone side, you first need to make the http request. You can do that with iOS classes but wrappers like ASIHTTPRequest make it much easier. Once you get the response back, you have to parse it. If you choose XML the iOS classes offer simple ways to parse the xml response. If you choose JSON, there's classes like SBJSON.
http://allseeing-i.com/ASIHTTPRequest/ - (Read this ASIHTTPRequest blog before using)
https://github.com/stig/json-framework
rest web services in iphone
There's also a much higher level framework called RESTKit which makes the iPhone side much easier.
https://github.com/RestKit/RestKit
Hope that helps tie it together for you.
EDIT:
Adding the create new user scenario:
The client creates a user object with the data (username, password etc...) and sends an HTTP PUT request to http://yourserver/myservice/users. The client serializes the user object to JSON/XML in the body.
What is the recommended/effective request payload for a REST PUT method?
PUT vs POST in REST
The server receives the request. On the server, you have a WCF "myservice" service (it's a class). It has a "public User CreateUser(User user)" method. In that method it creates a user object by doing whatever it has to do (call database etc...). It returns the User object because perhaps the server added info like the user id. The article below has a put request example.
http://damianm.com/tech/building-a-rest-client-with-wcf/
The client would get the response and the user object with all the details like id, etc... would be in the body as JSON/XML. It would deserialize that into a User object on the phone.
The server could also expose things like:
/User/{id} --> public User GetUser(string id);
I'd strongly recommended to rely on the HTTP protocol. Don't implement your own networking protocol!
Use GET requests to fetch data from the server and POST requests to send big amounts of data from the client to the server.
In order to structure your data, encode the data using JSON.
Here is a nice tutorial that explains how to do that with ASIHTTPRequest and JSONKit: http://www.icodeblog.com/2011/09/30/dynamically-controlling-your-application-from-the-web/
And yes, you can run the server on your working machine.
You can do this fairly easily with ASIHTTPRequest. It's a free 3rd party solution that can talk to different types of web services.
ASIHTTPRequest website
Not sure if this answers your question, but just as a suggestion so you don't have to deal a lot with server side stuff, use Parse
Related
I have a web application that is split into two sections, website and API.
The website sits within the DMZ so is segregated from our internal network, for this reason all data access is done via the API which is internal.
Our Seq server is internal. Therefore anything I log in the website would need to be passed to the API first for it to then then log.
I can do this with a basic string, but struggling when attempting to serialise the structured message for it to be picked up in the API (and sent to SEQ).
I'm looking for a way for Serilog to pass it's structured data across the wire to be stored in SEQ by the API (using Serilog or other).
The API is also logging it's own events so the answer would need to ensure it can continue.
I have found a number of sinks that send over HTTP - but how would I receive this back into Serilog/SEQ?
I need to store data received from a remote device, i.e Application needs to run 24 hours so that it can capture data and store it in database.
I am confusing whether to create a console application, web application or any other i need to develop which will run continuously.
If you already have the application developed, then send the data to a web service. if you don't, consider creating a web page, either using ASP.Net or something like JQuery Mobile and push data to HTTP Handlers or Web Service.
If you go down the web service route, create a web method that accepts a request object and returns a response object. It should be a pretty simple design.
I am creating an ASP.NET MVC website that uses a 3rd party API (web service) as a data source. It is read-only, and to date has been accessed by individuals using desktop applications (most in C#). I would like to consume this API using a web site in order to centralize information and give users historical information, automate certain repetitive tasks, and more easily allow sharing of information among users.
The desktop clients today experience throttling, and if you make repeated requests to the API using a client your IP will be throttled and/or banned. I think that if I made the requests to the API from my website, its IP would be banned the moment it saw any significant use.
Let's assume that I cannot work something out with the API owners. Probably the easiest way to work-around this problem is to do all of the API access using AJAX. When the user visits the website, he makes the requests to the API using AJAX then turns around and posts them to my website. I don't like this idea for multiple reasons-- first, it'll be slow, and second, I could not guarantee that the data sent to my website was genuine. A malicious user could, for whatever reason, send me bad information.
So I thought a better idea would be to establish a man-in-the-middle. The user would still be forced to make the AJAX request, but they would make it to a proxy or something else that I control, which would then forward it on to the real API and intercept the response so I could be a little more certain that the data I retrieved was genuine.
Is it possible to create such a "proxy"? What would it entail? I would like to do it using a .NET technology but I'm open to any and all ideas.
EDIT: It seems I caused confusion by using the word "proxy." I don't want a proxy, what I want is a pass-through that allows me to intercept the response from the API. I could have the client make the request and then subsequently upload it, but I don't want to trust client, I want to trust the API.
Let me explain this in shorter form. There is a client on a user's machine which can make a request to an API to get current information. I would like to create a website that does the same thing, but I am considering the possibility that the API web service may notice that while previously it was receiving ten requests for ten users from ten different IPs, it is now receiving ten requests for ten users from one IP and block that IP seeing it as a bot even though every request was kicked off by a user request just as it had previously. The easiest way to workaround this is to have the user make the request and then upload the response to me, but if I do that I am forced to blindly accept data from a client which is a huge no-no for any website in any situation. If instead I can place something that forwards the request along to the API preserving the IP of the user but is also capable of intercepting the response thereby proving that the data is authoritative, that would be preferred. However, I can't think of a software mechanism to do this-- it seems like it would need to be done at a different layer.
As for legal concerns, this is a widely used API with many applications and users (and there are other websites I have found using the API), but I was unable to find any legal information like terms of service beyond forum postings in the API's tech support section amounting to "don't make repeated requests, obey our caching instructions" etc. I can't find anything that would indicate this is an illegal or incorrect use of the web service.
You could implement your proxy. It wouldn't need to be AJAX though, it could just be a normal web page request that displayed the API results if you wanted.
Either way, in .Net you could do it using ASP.Net MVC. If you wanted AJAX, use a Web API controller action that implements the source API, if you want a web page, just use a regular MVC controller/action.
Inside your controller, you would just make a web request to the source, passing through the parameters.
In order to avoid throttling, you could cache the results of each request you make from your server (using the normal ASP.Net cache), so that if another client attempted to make the same request, or a similar one maybe, you could return the cached results instead of making another request to the API.
You would have to determine how long the results should be cached for, depending on how up to date the data needs to be in your client. E.g. For weather data, caching for an hour would seem OK. For more fast moving data it would have to be less. You have to strike a balance between avoiding throttling and keeping data fresh.
You could also intelligently fetch more data than you need at each request and then filter the result set that you return to your client. This could give you a better cache hit rate.
After searching the entire day about what I should use, I'm not sure what option would be best for my needs so I hope someone with more experience could help me out.
I have a winforms application (c#) and a ASP.NET MVC 4 web application (c#).
I wish to connect these, the goal is to send and receive data from the database which I use in the MVC 4 project, but from within the windows forms application. The data I send from the windows forms application to the database, is then used by the MVC 4 web application.
I am entirely new to web services / Web Api's so I can't really decide what option would be best. Any help would be much appreciated..
If you already created MVC4 project then you can add actions to any controller
and return JSON data like below :
public JsonResult GetCategoryList()
{
var list = //return list
return Json(list, JsonRequestBehavior.AllowGet);
}
or you can create new project of MVC4 and select WEBAPI template . It will create webapi project for you .It will create with example .so it will easy for to create webapi.In webapi it return data automatically convert to xml and json as per request
The WCF Web API abstractions map to ASP.NET Web API roughly as follows
WCF Web AP -> ASP.NET Web API
Service -> Web API controller
Operation -> Action
Service contract -> Not applicable
Endpoint -> Not applicable
URI templates -> ASP.NET Routing
Message handlers -> Same
Formatters -> Same
Operation handlers -> Filters, model binders
Other Links
If you have an MVC 4 App already, it would be better to use Web API (RESTful service)
I assume you have some knowledge in building REST API (understanding of POST, PUT, UPDATE stuff)
It is simple in configuration and usage. All what you need actually is to create a new controller like:
class MyApiController: ApiController {
public Post(SomeClass item) {
....connect to db and do whatever you need with the data
}
}
You'll also should configure routing for Api.
And then in your winForms app you can simply use HttpClient class to perform api call.
HttpClient aClient = new HttpClient();
// Uri is where we are posting to:
Uri theUri = new Uri("https://mysite.com/api/MyApi");
// use the Http client to POST some content ( ‘theContent’ not yet defined).
aClient.PostAsync(theUri, new SomeClass());
Take a look at some implementation details right here:
Web Api Getting Started
Get started with WCF is not so easy as with Web API.
Given the tags you've used, my guess is that you're deciding between SOAP Web Services and WCF. Given these two, I say to go WCF. SOAP web services (as implemented in Visual Studio) are the older technology; still serviceable, but WCF can do everything an older SOAP service can do (including look exactly like a SOAP service) and more.
If you have a web service that connects your web server to your database server (these two things should be on different machines; your web server is exposed to the world by necessity, while your DB server should be locked down like Fort Knox), I see no reason why you shouldn't use that same service as-is for an internal WinForms application (using a LAN/VPN to access the service layer on the DB server). For a WinForms application that must access the data over the Internet, I would recommend reimplementing the service as a WCF service supporting secure encrypted data transfer. You can also set up the service endpoint to only accept HTTPS connections, and thus simply run your existing service through SSL/TLS.
What you choose will primarily depend on how much time-resources you can commit to resolving the problem; moving to HTTPS is a fast fix requiring little if any code changes, while reimplementing in WCF will take more time but will allow additional security measures beyond a simple secure tunnel.
Or something lightweight like Nancy: http://nancyfx.org/
We had some issues with MVC4 WebApi stuff and ended up using ServiceStack on the server side JavaScript/AJAX for web clients and RestSharp for thick clients.
One of our specific issues was the inability to auto generate documentation, significant performance differences, and better support for unit/integration testing.
Rather than advocate specifically WCF, I'd recommend WCF Data Services or OData, with the stipulation that you'll need to secure it. If you go for pure WCF, you'll see that you'll end up creating a lot of code to handle retrieving the info from a database, and then sending that information right back out to your clients. It doesn't sound that bad, at first, but after about 30 entities in a database, you'll quickly grow tired of a pure WCF solution.
OData is great, it uses Entity Framework, and it quickly opens data manipulation for an existing database or one you are going to make. It will save you a ton of development time, if you can make your service secure. The format of the data response is flexible. There are plenty of client libraries ported for other programming languages as well.
The steps for securing a service are pretty simple. Always deploy to https. Any login or registration methods , need to be post methods, that return a token (Encrypted value), or a unique secret that can be encrypted and sent back for any subsequent requests. It's better to use the token, and have an expiration on the token.. because otherwise both your service and your app whether mobile or desktop, need to have a shared encryption / decryption method.
I am new to web services so I created a web service to replace my current in-app DB transactions. I wanted things to be safer so that is why I went this way.
When using a free packet sniffer, it instantly grabs my web service ASMX call. The problem with this is that using a program such as fiddler they can easily see the data going back and forth and even worse set up a auto responder.
Is there a way to hide the calls being sent to the web service to hide from packet sniffers? Or at least make it more difficult to see the calls?
Expose it over a secured channel (such as SSL) only for transport level security.
Alternatively, you may choose to implement WS-Security to validate the identity of the callers, sign the payload or encrypt the payload (partially or fully); or any combination of the above.
Here is an article that talks about this in the context of ASP.NET: http://msdn.microsoft.com/en-us/magazine/cc188947.aspx