I'm creating a web forms project in c#.
One of the key requirements is to post out to an API, however there's not one but several API's available.
At present the HttpClient object is uniquely defined for each API in a different namespace, like below:
MyCo.Myapp.PostApi.Client1.ClientObject
MyCo.Myapp.PostApi.Client2.ClientObject
Aside from the HttpClient, the endpoint url and mediatypes are stored as well as a few other configuration objects.
The idea being that the namespace Client1 or Client2 is stored in a database, and can be used to retrieve the location of the correct API, to create the object.
None of the above is set in stone - it's in concept form - so I wondered if there are any other alternatives to this solution which I can consider.
Any advice appreciated.
This seems like a potential candidate for an Abstract Factory approach. What you're describing sounds familiar to how one would connect to various database types using System.Data.Common
var settings = GetInfoFromDatabase();
var factory = ClientObjectFactory.Create(settings);
var clientObject = factory.CreateClientObject();
clientObject.Post(""); // This could be any of the client objects.
However since you don't have control over client APIs you could have the underlying factory perform the post:
factory.Post(clientObject, data);
Related
We are building our first small implementation of ServiceStack and we need some clarification regarding DTO's located in a separate assembly that is shared between the client and the server.
The WIKI page for the new API recommends the following for DTO
In Service development your services DTOs provides your technology agnostic Service Layer which you want to keep clean and as 'dependency-free' as possible for maximum accessibility and potential re-use. Our recommendation is to keep your service DTOs in a separate largely dep-free assembly.
There is also this snippet
*But let's say you take the normal route of copying the DTOs (in either source of binary form) so you have something like this on the client:
[Route("/reqstars")]
public class AllReqstars : IReturn<List<Reqstar>> { }
The code on the client now just becomes:
var client = new JsonServiceClient(BaseUri);
List<Reqstar> response = client.Get(new AllReqstars());
Which makes a GET web request to the /reqstars route. When a custom route is not present on the client it automatically falls back to using ServiceStack's pre-defined routes.
My question is... does the "largely dep-free" assembly still require a dependency on ServiceStack due the the route attribute on the DTO classes?
The [Route] attribute exists in the ServiceStack.Interfaces project, so you still only need a reference to the dependency and impl-free ServiceStack.Interfaces.dll. This is by design, we want to ensure the minimum dependency as possible which is why we'll try to keep all metadata attributes you might use on DTO's in the Interfaces project.
The reason for wanting to keep your DTO's in a separate assembly is to reduce the dependencies required by your clients in order to use it. This makes it less invasive and more accessible for clients. Also your DTOs represent your Service Contract, keeping them separate encourages the good practice of decoupling them from the implementation, which you want to continue to be free to re-factor.
I am using Monotouch to develop an iPhone App. I am using a web request to call a service that returns a cookie. My main aim is to be able to use the cookie as needed for web requests in various view controllers. I am assuming using the Shared Storage for the cookie is the way to go.
I have had a go at this and found the following hurdles:
The HttpWebResponse has a cookie collection made up of System.Net.Cookie objects.
The NSSharedStorage object only takes NSHttpCookie objects.
I haven't been able to figure out a way to turn a System.Net.Cookie object into an NSHttpCookie object. This is mainly because NSHttpCookie has only readonly properties and I am not sure how to create one using the constructors/static functions in C#.
So I really have two questions:
Is inserting the cookie into shared storage the best way to achieve my aim?
If so, how do I do this?
UPDATE:
Just to clarify a little further. The answer here is doing the opposite of what I want to do.
I don't think there's such thing as a NSSharedStorage. Is NSHTTPCookieStorage what you mean? If so, this wouldn't work for you. As per the documentation: "Cookies are not shared among applications in iOS". There also isn't a quick way to do what you want. You'll have to do something like what is suggested in the link you provided in your update. i.e. create an extension method (or some kind of utility method) that does the conversion.
You will likely have to manage your own collection of System.Net.Cookies in your app.
I am having an issue similar to this question:
Problem with WCF and Multiple Namespaces
The major difference I am having is that I don't control both ends of the wire. My setup is similar to this:
My.Objects
My.LoginService
My.Service1
My.Service2
The first thing you do is login via the login service and receive a security ticket. The ticket object is located in the My.Objects namespace. For each subsequent call in My.Service1 and My.Service2 you have to pass in the security ticket to authenticate the call. The issue I am having is that instead of the client (a .net one for now but Java and others in the future) seeing one My.Objects.Ticket the references are resolving as My.LoginService.Ticket, My.Service1.Ticket, and My.Service2.Ticket. When the client tries to pass the object retrieved during login to any other function it is receiving an object mismatch error.
How can I make each service resolve objects to the My.Objects namespace?
Have a look at the NetDataContractSerializer, might be what you're looking for. It's different from the DataContractSerializer in that it includes the CLR type information in the serialized XML which allows you to share your type but forces both ends of the wire to use the same type.
Have a look at a blog post I put together and an attribute (from another blog I stumbled across) to inject it on operations that needs to use it:
http://theburningmonk.com/2010/08/wcf-using-the-netdatacontractserializer-to-share-your-type/
Create an assembly referencing one of the services with a ticket type and then reference this assembly from your main project.
There is an easy way to share types between client and service, just by adding reference to shared type assembly to your client BEFORE adding the service reference.
You can find the detailed scenario and sample project there:
http://blog.walteralmeida.com/2010/08/wcf-tips-and-tricks-share-types-between-server-and-client.html
I have an asp.net MVC2 application that needs to call a web service from the controller. How do I do this? It is a RESTful service that returns Json data.
I cant seem to find a good example.
Thanks
You call it the same way you would do in any ASP.net application, it is not connected to MVC at all.
Either add a reference and use that (easiest) or go with the manual method: here is a guide, see at towards the end (fig. 14 in particular) for consuming such services:
http://msdn.microsoft.com/en-us/magazine/dd943053.aspx
I have written my own ActictiveResource client framework, which allows the consumer to specifiy the http provider and the serialisation provider. The generic activeResource class has the four main verbs (get,put,post,delete) as methods which it calls against a specified resource url, passed in at cunstruction. the fololwing is an example of getting a product item from teh service:
ActiveResource<Product> arProduct = new ActiveResource<Product>(jsoSerializer,liveHttpProv,"https://company/product/1452");
//Get verb
Product prod = arProduct.Get();
Of course you can also use the other verbs on the object to put, post and delete.
arProduct.Post(prod);
The code, basically, wraps up the underlying http post,put, get functions and takes care of the serialiasation of the payload to objects. It has been a very useful component which I have used over and over again. The code can be easily called from a controller, it may be worth using a IOC container (I am using Th eUnity block) to instatiate you providers
Hope this helps
I would put together a simple class that acts as a "client" that makes a web-request from the URL, and then return the response as a string.
From there you can deserialize the JSON data using either the JSON serialization that ships with WCF, or the most excellent JSON.Net library. You will need to create a simple data class that is structured in the same way as the JSON data your expecting back.
You could also combine the two and have your client class return the deserialized object directly.
I have an application which consumes both a WCF service and an ADO.NET Data Service. Types are shared between the server and client using a shared class library.
When I configure the service reference for the WCF service, I can choose to use the existing types in the class library to avoid creating duplicate types in the proxy classes.
But Visual Studio doesn't offer me the option to do that on the ADO.NET Data Service.
Is it possible for an ADO.NET Data Service to reuse existing types?
Great question.
Yes this is definitely possible.
I just put together a Tip that show you how to turn off default Code-Gen and reference an existing type instead, and showing how too tell the DataServiceCpntext how to do the mapping between the type expected on the wire and the type used on the client.
NOTE: that even though the Types might be the same inside the DataService and on the client it is still possible that the Data Service has been configured to expose the Server types in a different namespace, so this mapping may still be required.
Anyway I'm sure Tip 52 will help you get your scenario working.
Alex
Way i would do is instead of creating proxy through add service option.
Use DataServiceContext directly
then can use
Execute<TypeOfData> method