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 :)
Related
I'm looking for a way to interpret an OpenAPI .json definition. This is my workflow:
The user provides the .json file during runtime.
I would like to show all existing endpoints, their HTTP methods, parameters and expected bodies like e.g. Postman or Swagger are doing it.
The user can choose one endpoint and an HTTP method, then provide all needed parameters and send a request. As soon as I retrieve the response I will show it as plain text to the user.
The user can choose an endpoint and HTTP method and I will serialize the information needed to do step 3. later again without reading the whole .json file again.
I googled and tested a few libraries but did not find one or multiple which do exactly what I'm looking for.
I think OpenAPI.NET might do the reading job necessary for step 2.
Regarding the part that's able to trigger the HTTP request I only found fully-fledged "Client Creators" which take an OpenAPI .json and create C# code which can then be compiled to get a full client library. Many of these "Client Creators" are also build up on other tech stacks (e.g. Java) and make it difficult to use from a .Net application.
I had a deeper look into NSwag which is written in C# and can be installed as a NuGet but again this one creates C# code that needs to be compiled and it also seems it creates way more then I need (deserialization and handling of Non-OK status codes etc.)
I would just need a way to create something like a System.Net.Http.HttpRequestMessage or RestSharp.RestRequest. I could have a look into what it needs to create them by my own but I fear to reinvent the wheel and miss some more specific parts of the OpenAPI specification.
Do you know any libraries that would help me achieving my workflow but especially step 3 and step 4 of it?
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.
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 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.