When you are using another web applications Restful API, do you usually use a wrapper library or do you use the Restful API directly with a HTTP client?
This is a hard question to answer, primarily because in the current state of the industry, the right answer is very impractical.
The correct answer, in my opinion, is you should not use a wrapper API. The uniform interface is HTTP and that should be the programming model the client works against.
Having said that, there is nothing wrong with having helper classes that parse media types to generate strongly typed versions. Something like this,
var response = HttpClient.Get(linkTofoo);
if (response.ContentType =='application/foo') {
var strongFoo = FooHelper.Parse(fooResponse);
HandleFoo(strongFoo);
}
Unfortunately, a vast majority of apis that claim to be RESTful, are not. They do not respect the self-description and hypermedia constraints and therefore they make it very difficult to interact with them in a RESTful way. They require you to do client side URI construction and have prior knowledge of the types that will be returned from endpoints.
The sad fact is that with many APIs you have little choice but to use a provided client proxy library. This should not be the case.
If you are looking for evaluating a client library, just make sure it is a stateless one. The client library should not start managing the lifetimes of the returned objects. Http caching does that, so unless it is an uber-smart library that can invalidate object references when the cached representation expires, avoid any stateful client libraries.
e.g.
var foo = remotelibrary.GetFoo(233);
var bar = foo.bar; // If this causes an HTTP request
var barcopy2 = foo.bar // and this doesn't because it already has a reference to bar
// I would be very leary of using this library
It is almost certainly going to be better in the long run to use a library. This allows you to abstract away the restful-ness of the design and ignore the whole HTTP business.
If there is not an existing library for whatever API you're using then you should consider writing your own.
Related
I have done some R&D on above libraries and have used some in my project.I am using Moshi for json parsing, OkHttp3 library for http connections and Rxjava for asynchronous and event based programming in my project. Now when I looked at retrofit, I felt its of no use as I have already used above main components of retrofit myself.
Just want to know the ideas of the people whether I am thinking in right direction or not.
Edit: From my point of view, Retrofit only provides clean interface of http client where one can customize requests,headers etc with annotations.
This is a good choice of libraries from my point of view. The first three are developed by Square and they work very well together. However the main difference is that each library works on a different layer.
OkHttp: transport layer. Deals with http protocol. Performs networking.
Moshi: Json parser. Transforms bytes from OkHttp into a Java objects.
Retrofit: Rest layer. Transforms HTTP logic (status codes), into REST logic.
RxJava: provides tools to create reactive code, instead of imperative code.
Can someone explain the difference between the two, when to use WebScriptServiceHostFactory vs WebServiceHostFactory? I understand when used they setup certain default behaviors on the endpoints so I don't have to. Otherwise the differences, is it just the WebScriptServiceHostFactory defaults to JSON messages, while WebServiceHostFactory defaults to XML (soap messages)? Using WebGet and WebInvoke, do both work on them, or does one not allow it? Also can I use UriTemplates, to build REST services, with either one?
The WebScriptServiceHostFactory is used almost exclusively to define services that will be consumed by the ASP.NET AJAX framework (it gives the JS client a "proxy" which can be used to call the service). If you're doing general-purpose WCF web (REST) programming, you should stick with the WebServiceHostFactory.
Some differences:
As you mentioned, the default response format is different (JSON in WScriptSHF, XML in WSHF)
UriTemplates are fully supported in WSHF, not in WScriptSHF
WebGet and WebInvoke work on both, but on WScriptSHF the only supported body style is WrappedRequest
Responses to calls to an endpoint created by WScriptSHF are wrapped in a JSON object; if the response to an operation (in JSON) was [1,2,3], the endpoint will return it as {"d":[1,2,3]}.
There may be others, but essentially, the guidance is to use the WScriptSHF only if you're using the ASP.NET AJAX framework (with the <asp:ScriptManager>) and the WSHF for everything else.
I am very new to remoting in flex. I am using flex 4.5 and talking to a web application built by someone else on the team using AMF. They have used Zend_AMF to serialize and unserialize the data.
One of the main issues I am facing at the moment is that I will need to talk to a lot of services (about 60 or so).
From examples on remoting I have seen online and from adobe, it seems that I need to define a remoting object for EACH service:
<mx:RemoteObject id="testservice" fault="testservice_faultHandler(event)" showBusyCursor="true" destination="account"/>
With so many services, I think I might have to define about 60 of those, which I don't think is very elegant.
At the same time, I have been playing with Pinta to test out the AMF endpoint. Pinta seems to be able to allow one to define an arbitary amount of services, methods and parameters without any of these limitations. Digging through the source, I find that they have actually drilled down deep into the remoting and are handling a lot of low level stuff.
So, the question is, is there a way to approach this problem without having to define loads or remoteobjects and without having to go down too deep and start having to handling low level remoting events ourselves?
Cheers
It seems unusual for an application to require that many RemoteObjects. I've worked on extremely large applications, and we typically end up with no more than ~6-10 RemoteObject declarations.
Although you don't give a lot of specifics in your post about the variations of RemoteObjects, I suspect you may be confusing RemoteObject with Operation.
You typically declare a RemoteObject instance for every end-point in your application. However, that endpoint can (and normally does) expose many different methods to be invoked. Each of these server-side methods gets results in a client-side Operation.
You can explicitly declare these if you wish, however the RemoteObject builds Operations for you if you don't declare them:
var remoteObject:RemoteObject;
// creates an operation for the saveAccount RPC call, and invokes it,
// returning the AsyncToken
var token:AsyncToken = remoteObject.saveAccount(account);
token.addResponder(this);
//... etc
If you're interacting with a single server layer, you can often get away with a single RemoteObject, pointing to a single destination on the API, which exposes many methods. This is approach is often referred to as an API Façade, and can be very useful, if backed with a solid dependency injection discipline on the API.
Another common approach is to segregate your API methods by logical business area, eg., AccountService, ShoppingCartService, etc. This has the benefit of being able to mix & match protocols between services (eg., AccountService may run over HTTPS).
How you choose to split up these RemoteObjects is up to you. However, 60 in a single applications sounds a bit suspect to me.
I am creating a node.js module which communicates with a program through XML-RPC. The API for this program changed recently after a certain version. For this reason, when a client is created (createClient) I want to ask the program its version (through XML-RPC) and base my API definitions on that.
The problem with this is that, because I do the above asynchronously, there exists a possibility that the work has not finished before the client is actually used. In other words:
var client = program.createClient();
client.doSomething();
doSomething() will fail because the API definitions have not been set, I imagine because HTTP XML-RPC response has not returned from the program.
What are some ways to remedy this? I want to be able to have a variable named client and work with that, as later I will be calling methods on it to get information (which will be returned via a callback).
Set it up this way:
program.createClient(function (client) {
client.doSomething()
})
Any time there is IO, it must be async. Another approach to this would be with a promise/future/coroutine type thing, but imo, just learning to love the callback is best :)
Instead of using the web services infrastructure provided by .net, I was wondering what your take on rolling my own asp.net page that you can post data to (I guess all the cool kids are calling this REST,) and retrieving a JSON response from. Is there additional overhead in using an aspx page for this purpose that i'm not aware of?
Yes and no. You can use ASP.NET, even without MVC, to handle this rather effectively. But you probably don't want to use pages. Rather, you should implement IHttpHandlers for your rest actions.
As for handling the JSON angle, check out JSON.NET if you don't want to use the baked-in WCF/Scripting stuff.
Even if you'd use existent helper classes, you'd have to implement your own message parsing (including error handling etc.) and thus lose transport transparency (would require more effort to switch to other protocols/formats) unless you implement a communication infrastructure similar to WCF's. And then you might need additional features such as security..... just use WCF if you can ;)