So I have implemented a C# RESTful API for a recent side project and I have noticed that when making a GET request to the API I am provided with a lot of data when I only need around 8 or so entries, specifically the newest entries.
I have narrowed down this too one of two different issues, I believe my below fall back code to be somewhat primitive following a generic class structure that is created when deseralize object is called. The main problem could be because I am using a web client to download the JSON data then passing it over, could this be more sophisticated to allow the functionality I want?
using (WebClient wc = new WebClient())
{
var json = wc.DownloadString("//api call here");
jsonData = JsonConvert.DeserializeObject<List<T>>(json);
}
I am of course using NewtonSoft Json libary here.
Or secondly could it be that I need to make changes to the controller to allow a way for me to request only the 8 newest entries? I have little knowledge of changing API's other than allowing the VS magic to happen.
I mostly seek you're advice here because I could be worried about nothing but I just think my approach is wrong and if the data starts getting larger I should be improving on my existing knowledge.
To provide clarity on how this problem was solved it was mostly done through creating specific triggers on the existing API that allowed SQL to be run which is something that was I previously didn't know.
This allowed me to limit the amount of data that was returned through a generic sql command. A separate call was created on the API which returned all of the data and loaded the later objects into the dom using an async function.
Yes you can use SQL with api's generated by C# magic.
Related
I am developing a software solution using Amaon mws api in c#, using the classes from their c# library. I would like to get the xml response info in raw form, not thru their classes which are a little clumsy for my needs. Is there anyway to get out the full xml info from the response object? Please reply
They've made it easy by serializing everything into objects for you. You can go through their Sample cs file (MarketplaceWebServiceProductsSample.cs for the Products API) and dig out the method you want to call and put it into your own app, and then make the call, get back the serialized objects and then you can do what you want with them, no need to look at raw XML.
However, if you want to, just add the code that is in the runtime-src folder of the client library to your project, set a breakpoint and step into the code. You'll find it in there eventually and then copy out the parts you need.
I've written about a dozen client applications that use the various MWS client libraries and I find them easy to work with. If you don't like their classes, just write a method that converts theirs to yours.
Im not very sure about C# library.But you can get raw xml response over http connection. You can refer this:
http://docs.developer.amazonservices.com/en_IN/feeds/Feeds_GetFeedSubmissionResult.html
All the best :)
I am using SugarCRM v.6.5.16
Soap: http://{CRM Path}/service/v4_1/soap.php
I have been tasked to create a program that reads values from a JSON string to input into SugarCRM.
The object creation of Account, Contact, Opportunity etc. is working just fine. I am however unable to the the set_realtionship or set_realationships from the SOAP API to work.
If possible could someone give me a quick example of how to make this work.
I have found very little documentation regarding coding in C# and SugarCRM SOAP functions. I can directly insert into the 'link' table but would prefer to utilize the API since somebody took the time to write it.
If REST would work better than SOAP an example of that would also be useful.
Thanks
It is with sights for the future recommended by Sugar to use REST. Advantages are that REST is faster than SOAP and REST will live longer in the product SugarCRM.
I've looked at quite a few of the questions on the site, but I'm still having trouble fulling understanding where to begin.
I've never done anything with webservices before, so bear with me.
The current project I've been assigned is to write a webservice that queries a database and returns the data back to the client. (using .NET 2008 programming in C#)
So far, I've been able to do basic data types no problem, but I'm not 100% sure where to go from there. I've been returning an XmlDocument type, but I'm not sure that that's the best way, or even the correct way to do it.
Currently creating an ASP.NET Web service, though it's been suggested I use a WCF Web service.
Can anyone shed light on where to go from here? Or perhaps a a link to a tutorial on sending and recieving large amounts of data via webservices?
EDIT: The answers are great so far, but I'm still not 100% sure how to answer. I think the webservice will be interacted with a combination of client programs, but also websites, if that is all possible... That's how new I am to this.
Depending on the structure of the data that you're sending back to the client, I wouldn't recommend using XmlDocument as the return type. It will add a lot of unnecessary bulk to your response.
You really didn't state the protocol that you want to support, but if you're transporting data via HTTP, then sending your data back to the client as a JSON-formatted string would streamline it better.
You can define that you're returning your complex type formatted as JSON like this:
[WebGet(ResponseFormat=WebMessageFormat.Json, UriTemplate="GetComplexObject/{id}")]
public MyComplexType GetComplexObject(int id){
//do work to get your object
return myObject;
}
WCF will take care of serializing your object as JSON if MyComplexType is defined as a DataContract...
[DataContract]
public class MyComplexType{
[DataMember]
String Name {get;set;}
}
If you're looking for REST-ful services, then WCF is probably the preferred approach using the WebHttp functionality.
The WCF team put together a great series of walk-throughs on using WCF WebHttp (which is new to .NET 4). They assume a little knowledge of web http programming, but they're pretty good and hopefully help put you on the right track.
I hope this helps!! Good luck.
http://msdn.microsoft.com/en-us/library/ms733127.aspx
WCF uses this concept of a data contract - which provides serialization help on complex objects.
If you decide to use WCF there is a tutorial available at : http://dotnetslackers.com/articles/ajax/JSON-EnabledWCFServicesInASPNET35.aspx .
In general, this article gives a walk through of building an ASP.NET web service that sends JSON.
JSON is faster than XML, and is becoming a standard for most new web services. I highly recommend the JSON.NET library for JSON serialization.
There are two ways that I have implemented this using a regular ASPX.NET web service:
Have the same underlying object libraries on the client and the server and functions to translate the data from the web service object to the client object.
Have the same underlying object libraries on the client and the server and pass data to/from the server as a string representation of the data object (usually XML format, but could be JSON or another similar format)
The first option I found is VERY cumbersome. The web service will claim that its versions of the libraries are unique, even if you have the same classes/objects on both the server and the client. Even if the namespace is the same, the object returned from the web service will have the web service namespace in it somewhere, so you have to write functions to convert them. I know of a way to fix this, but it is not worth the effort, at least not for me.
The second option is the one I am using right now. I again have one library on both client and server. It has objects that get and hold data from the database. I then have generic utility functions that serialize objects to and from XML strings. When I send data from the server I serialize it to an XML string on the server and deserialize it at the client. I do the reverse when sending data to the server. I also break up large amounts of data being passed to/from the web service to reduce errors and data transfer time.
WCF may be better. Never used it. But the above is what I have done with standard web services.
The best way to send data back to client it's throught xml, because almost all languages know how to handle xml document.
If you want to return something that it's in some way language dependent is't not worst to implement if you want your web service to be implemented using virtually all languages posible.
Another posibility is to return json objects.
I think this question is like clay pidgeon shooting.. "pull... bang!" .. shot down.. but nevertheless, it's worth asking I believe.
Lots of JS frameworks etc use JSON these days, and for good reason I know. The classic question is "where to transform the data to JSON".
I understand that at some point in the pipeline, you have to convert the data to JSON, be it in the data access layer (I am looking at JSON.NET) or I believe in .NET 4.x there are methods to output/serialize as JSON.
So the question is:
Is it really a bad idea to contemplate a SQL function to output as JSON?
Qualifier:
I understand trying to output 1000's of rows like that isn't a good idea - in fact not really a good idea for web apps either way unless you really have to.
For my requirement, I need possibly 100 rows at a time...
The answer really is: it depends.
If your application is a small one that doesn't receive much use, then by all means do it in the database. The thing to bear in mind though is, what happens when your application is being used by 10x as many users in 12 months time?
If it makes it quick, simple and easy to implement JSON encoding in your stored procedures, rather than in your web code and allows you to get your app out and in use, then that's clearly the way to go. That said, it really doesn't take that much work to do it "properly" with solutions that have been suggested in other answers.
The long and short of it is, take the solution that best fits your current needs, whilst thinking about the impact it'll have if you need to change it in the future.
This is why [WebMethod] (WebMethodAttribute) exists.
Best to load the data to to the piece of program and then return it as JSON.
.NET 4 has a support for returning json, and i did it as a part of one ASP.NET MVC site and it was fairly simple and straightforward.
I recommend to move the transformation out of the sql server
I agree with the other respondents that this is better done in your application code. However... this is theoretically possible using SQL Server's ability to include CLR assemblies in the database using create assembly syntax. The choice is really yours. You could create an assembly to do the translation in .net, define that assembly to SQL Server and then use contained method(s) to serialize to JSON as return values from your stored procedures...
Better to load it using your standard data access technique and then convert to JSON. You can then use it in standard objects in .NET as well as your client side javascript.
If using .net mvc you serialize your results in your controllers and output a JsonResult, there's a method Controller.Json() that does this for you. If using webforms an http handler and the JavascriptSerializer class would be the way to go.
Hey thanks for all the responses.. it still amazes me how many people out there have the time to help.
All very good points, and certainly confirmed my feeling of letting the app/layer do the conversion work - as the glue between the actual data and frontend. I guess I haven't kept up too much with MVC or SQL-2008, and so was unsure if there were some nuggets worth tracking down.
As it worked out (following some links posted here, and further fishing) I have opted to do the following for the time being (stuck back using .NET 3.5 and no MVC right now..):
Getting the SQL data as a datatable/datareader
Using a simple datatable > collection (dictionary) conversion for a serializable list
Because right now I am using an ASHX page to act as the broker to the javascript (i.e.
via a JQuery AJAX call), within my ASHX page I have:
context.Response.ContentType = "application/json";
System.Web.Script.Serialization.JavaScriptSerializer json = new System.Web.Script.Serialization.JavaScriptSerializer();
I can then issue: json.serialize(<>)
Might seem a bit backward, but it works fine.. and the main caveat is that it is not ever returning huge amounts of data at a time.
Once again, thanks for all the repsonses!
I was curious as to how I would accomplish the following with webservices:
Authenticate a user.
Accept a CSV or XML file.
Process the file and put it into an SQL database.
Someone mentioned in a previous post that I should use a webservice. I can't seem to find any resources that explain how to begin something like this. All the simple examples seem to just show how you can serve XML given a query.
I want to know how to accept stuff and also, how this would differ from an upload control on an authenticated webpage. I don't think I really understand webservices and their benefits.
How would the user sending the XML file interface with my webservice?
If you want to do large file uploads, then a web service may cause some issues, because some web service platforms (including .NET) have default settings limiting the size of the data.
The advantage of a web service is that it does all the mapping of the request to/from XML, so you can return a .NET type, and don't need to muck around with processing request parameters.
However, you may have to put more effort into maintaining state, etc.
For logins, what you can do is have a login function that returns some kind of identifier which can be used to verify the user as valid for that session - one way of doing this being to have columns in your user table for lastActive and sessionGUID, and when they log in you generate a new sessionGUID and return that, and on that and any other valid request they make you update the lastActive, and if there is a request too long after the lastActive time, then you refuse the request... there's any number of similar ways of doing that, but hopefully you get the general idea - you don't want to require the login details each time, but you can generate a temporary identifier and use that.
For accepting an XML file, you'd want to use something like XDocument or XMLReader to read the data that you receive. Assuming you're not talking about the parsing of the XML format that the web service itself uses, you're most likely to be receiving a string and then pushing that into an XDocument and then using the standard XDocument functions to process the data. If the document would be large, then XMLReader should be more efficient.
For reading a CSV file, there are some (free and non-free) CSV readers which help avoid some of the issues you can have, giving you a nice API for processing a string or strings of CSV data. If you know that the source data doesn't have non-structural commas, though, you can just take the string and split it by commas, and then strip any quotes around the values. That tends to get flaky quite fast if there might be addresses or other data that could have commas in, though.
The XML should be able to be passed via the web service just fine - it should be encoded and decoded, so it's then compliant strings being passed out.
As for storing it in a database, there's any number of ways to do that - you can use ADO.NET to store things in a database without further libraries, you can create a database structure in Visual Studio or SQL Server Management Studio and then use SQLMetal or Linq to SQL to generate classes for saving the data, you can use a 3rd party database mapping tool (such as Castle ActiveRecord), or whatever. It depends what you know and how much you're willing to learn. That's really separate to the web service. When you define a web service in .NET you effectively define standard functions with attributes marking them as web services, so the database side is standard .NET database stuff that's not necessarily any different to what you'd do for an ASP.NET website, or even a desktop program.
A web service is not really appropriate for sending an arbitrary file. It can be done, but if that's your only reason for creating the web service, you might as well just stick to HTTP.
If the file has a specific format or specific contents then you might want to create a web service for that. The purpose of an ASMX or WCF web service is to provide discoverability and strong typing to the data (among other things, but I'm sticking to the basics for the moment). From the perspective of the client, instead of trying to create some ugly XML or CSV blob and chuck it over HTTP, you use an actual service proxy with POCO classes:
MyService service = new MyService();
MyData data = new MyData() { ID = 3, Name = "Test", Date = DateTime.Now };
service.Save(data);
Visual Studio (and equivalent tools in Java and some other platforms) will take care of generating the proxy for you, so really all you have to do is write the above code.
But if you're just trying to send any data, this won't get you anywhere, because you can't generate a proxy for raw XML. Well, you can, but it would just be an XmlDocument and that accomplishes nothing in terms of usability, type safety or discoverability.
Don't get confused by the "XML" in "XML Web Service". It's not a tool for sending around vanilla XML. Rather, XML refers to the format of the message, as it is transmitted over the wire, as opposed to a POST string (id=3&name=Test&date=2010-01-24) or a binary RPC call as used in .NET Remoting.
In terms of authentication, if you do decide to use WCF, you just have to use the right binding. A WCF proxy is normally configured by default to use wsHttpBinding, which uses integrated Windows authentication to secure the messages. Again, assuming you use Visual Studio, this is all done pretty much automatically for you unless you decide to change the defaults.