I am working with another team that is providing me a web service to call.
The web service has a few methods that I can call and it gives response values.
I recently found out that they are coding it as a "RESTful" service. I am not very experienced in RESTful services, but to my (very limited) understanding, traditional method calling is not what REST is about (though it can be done).
Is REST the wrong approach if all you are doing is creating custom web methods to call?
NOTE: I think this is the other teams first real experience with web services. I am worried that they have been beguiled by the REST buzz and are not using the best protocol for what they are building.
What you are describing sounds to me as RPC over HTTP and that can't be called REST as you are basically at level zero of the Richardson Maturity Model.
REST is an architecture style which allows a lot of freedom in the implementation. But you still have to respect the REST constraints, mainly the HATEOAS.
Is REST the wrong approach if all you are doing is creating custom web methods to call?
In most cases SOAP is used for this scenario, but people are somehow afraid of SOAP (maybe because of it's bad reputation for being called "Simple" when it wasn't) and prefer to go for something simpler which is basically a HTTP RPC API that they believe is actually REST, when it isn't.
In conclusion, you can keep your web service as it is - if it's safe and meets your needs - but you can't call it REST. It's RPC.
Need some expert opinion on this case study.
Problem Statement/Scenario:
My WCF client/proxy continually requiring some lockup data from relevant WCF service. More precisely, I've a WCF service that provides Location data (City/Country etc) from a database (although data is cached on Service). Some how I want to avoid Serialization/DeSerialization (Object contains a lot of associated properties as well as inner objects) cost and service operation execution for better throughput.
Few days back I studied WCF behaviors/WCF extension methods.I found an interesting article on MSDN (http://msdn.microsoft.com/en-us/magazine/cc163302.aspx). After reading this article I thought this could help me to improve performance of my service. So before implementing this I want to confirm that either I'm thinking in right direction or any other solution can solve my problem.
I'm thinking to implement Dispatcher Extensions to solve this problem instead of Proxy (Client) Extensions. I've following queries?
I) Where (Proxy/Service level) I need to implement extensions?
II) When implementing Dispatcher Extensions my call will not send to actual service and I'll save Serialization/DeSerialization cost. Right/Wrong?
III) Implementing Dispatcher Extensions in my case is also better, because why need not to bother about which proxy interface method call occurred as caching logic is on service side. Right/Wrong?
Please suggest me a better solution as I want to save Serialization/DeSerialization cost as well as I want to implement data caching.
Thanks in advance
/Rizwan
There are two ways I've incorporated WCF caching in the past:
Using Castle DynamicProxy to generate proxies for my ServiceContract interfaces. These dynamic proxies use interceptors to perform caching. If the data is not in the cache, the interceptor creates a real WCF client (a ChannelFactory<TInterface>) and invokes the WCF operation, then caches the result. I like this approach, because the caching implementation isn't really WCF specific.
Implement an IRealProxy for WCF which wraps the actual remote operations and performs caching/retrieval as necessary. In principal, this is similar to approach 1, but the implementation is specific to WCF (with remnants of .NET Remoting). I used this approach before migrating to #1. I migrated to approach 1 because approach 1 let me accomplish caching on both the client and the server in an implementation agnostic manner. At the time, I rolled my own RealProxy, but it looks like someone else has since done the same and posted the code: http://blog.ngommans.ca/index.php?/archives/31-Custom-Proxy-Generation-using-RealProxy.html
I have a WCF service, DummyService. It implements IDummyService and lives on two URIs, http://1.1.1.1/DummyService and http://2.2.2.2/DummyService. I would like to create a routing endpoint such that;
I can hit http://1.1.1.1/RoutingService/DummyService?wsdl and/or http://1.1.1.1/RoutingService/DummyService
This uri appears to just be the dummyservice endpoint, i can build a client proxy, etc.
Any calls get round-robined around
Is there some way to do this without having IRoutingService re-implement DummyService? I want dummyservice to essentially be a plug-in that I can add/remove at runtime.. Can I do this with WCF Routing? Any samples I can reference? I havent been able to find anything on MSDN/Google, but perhaps im asking the wrong way..
This is pretty much exactly what WCF Routing is for.
There is a sample which is part of the WCF/WF samples (info here):
http://msdn.microsoft.com/en-us/library/ee667249%28v=VS.100%29.aspx
I was thinking about the architecture of a web application that I am planning on building and I found myself thinking a lot about a core part of the application. Since I will want to create, for example, an android application to access it, I was already thinking about having an API.
Given the fact that I will want to have an external API to my application from day one, is it a good idea to use that API as an interface between the interface layer (web) and the business layer of my application? This means that even the main interface of my application would access the data through the API. What are the downsides of this approach? performance?
In more general terms, if one is building a web application that is likely to need to be accessed in different ways, is it a good architectural design to have an API (web service) as the interface between the interface layer and business layer? Is REST a good "tool" for that?
Sounds like you've got two questions there, so my answer is in two parts.
Firstly, should you use an API between the interface layer and the business layer? This is certainly a valid approach, one that I'm using in my current project, but you'll have to decide on the benefits yourself, because only you know your project. Possibly the largest factor to consider is whether there will be enough different clients accessing the business layer to justify the extra development effort in developing an API? Often that simply means more than 1 client, as the benefits of having an API will be evident when you come to release changes or bug fixes. Also consider the added complexity, the extra code maintenance overhead and any benefits that might come from separating the interface and business layers such as increased testability.
Secondly, if you implement an API, should you use REST? REST is an architecture, which says as much about how the remainder of your application is developed as it does the API. It's no good defining resources at the API level that don't translate to the Business Layer. Rest tends to be a good approach when you want lots of people to be able to develop against your API (like NetFlix for example). In the case of my current project, we've gone for XML over HTTP, because we don't need the benefits that Rest generally offers (or SOAP for that matter).
In general, the rule of thumb is to implement the simplest solution that works, and without coding yourself into a corner, develop for today's requirements, not tomorrow's.
Chris
You will definitely need need a Web Service layer if you're going to be accessing it from a native client over the Internet.
There are obviously many approaches and solutions to achieve this however I consider the correct architectural guideline to follow is to have a well-defined Service Interface on the Server which is accessed by the Gateway on the client. You would then use POCO DTO's (Plain old DTO's) to communicate between the endpoints. The DTO's main purpose is to provide optimal representation of your web service over the wire, it also allows you to avoid having to deal with serialization as it should be handled transparently by the Client Gateway and Service Interface libraries.
It really depends on how to big your project / app is whether or not you want want to go through the effort to mapping your DTO's to the client and server domain models. For large applications the general approach would be on the client to map your DTO's to your UI Models and have your UI Views bind to that. On the server you would map your DTO's to your domain models and depending on the implementation of the service persist that.
REST is an architectural pattern which for small projects I consider an additional overhead/complexity as it is not as good programattic fit compared to RPC / Document Centric web services. In not so many words the general idea of REST is to develop your services around resources. These resources can have multiple representations which your web service should provide depending on the preferred Content-Type indicated by your HTTP Client (i.e. in the HTTP ACCEPT HEADER). The canonical urls for your web services should also be logically formed (e.g. /customers/reports/1 as opposed to /GetCustomerReports?Id=1) and your web services would ideally return the list of 'valid states your client can enter' with each response. Basically REST is a nice approach promoting a loosely-coupled architecture and re-use however requires more effort to 'adhere' to than standard RPC/Document based web services whose benefits are unlikely to be visible in small projects.
If you're still evaluating what web service technology you should use, you may want to consider using my open source web framework as it is optimized for this task. The DTO's that you use to define your web services interface with can be re-used on the client (which is not normally the case) to provide a strongly-typed interface where all the serialization is taken for you. It also has the added benefit of enabling each web service you create to be called by SOAP 1.1/1.2, XML and JSON web services automatically without any extra configuration so you can choose the most optimal end point for every client scenario, i.e. Native Desktop or Web App, etc.
My recent preference, which is based on J2EE6, is to implement the business logic in session beans and then add SOAP and RESTful web services as needed. It's very simple to add the glue to implement the web services around those session beans. That way I can provide the service that makes the most sense for a particular user application.
We've had good luck doing something like this on a project. Our web services mainly do standard content management, with a high proportion of reads (GET) to writes (PUT, POST, DELETE). So if your logic layer is similar, this is a very reasonable approach to consider.
In one case, we have a video player app on Android (Motorola Droid, Droid 2, Droid X, ...) which is supported by a set of REST web services off in the cloud. These expose a catalog of video on demand content, enable video session setup and tear-down, handle bookmarking, and so on. REST worked out very well for this.
For us one of the key advantages of REST is scalability: since RESTful GET responses may be cached in the HTTP infrastructure, many more clients can be served from the same web application.
But REST doesn't seem to fit some kinds of business logic very well. For instance in one case I wrapped a daily maintenance operation behind a web service API. It wasn't obvious what verb to use, since this operation read data from a remote source, used it to do a lot of creates and updates to a local database, then did deletes of old data, then went off and told an external system to do stuff. So I settled on making this a POST, making this part of the API non-RESTful. Even so, by having a web services layer on top of this operation, we can run the daily script on a timer, run it in response to some external event, and/or have it run as part of a higher level workflow.
Since you're using Android, take a look at the Java Restlet Framework. There's a Restlet edition supporting Android. The director of engineering at Overstock.com raved about it to me a few years ago, and everything he told us was true, it's a phenomenally well-done framework that makes things easy.
Sure, REST could be used for that. But first ask yourself, does it make sense? REST is a tool like any other, and while a good one, not always the best hammer for every nail. The advantage of building this interface RESTfully is that, IMO, it will make it easier in the future to create other uses for this data - maybe something you haven't thought of yet. If you decide to go with a REST API your next question is, what language will it speak? I've found AtomPub to be a great way for processes/applications to exchange info - and it's very extensible so you can add a lot of custom metadata and yet still be eaily parsed with any Atom libraries. Microsoft uses AtomPub in it's cloud [Azure] platform to talk between the data producers and consumers. Just a thought.
I am bit confused about ADO.Net Data Services.
Is it just meant for creating RESTful web services? I know WCF started in the SOAP world but now I hear it has good support for REST. Same goes for ADO.Net data services where you can make it work in an RPC model if you cannot look at everything from a resource oriented view.
At least from the demos I saw recently, it looks like ADO.Net Data Services is built on WCF stack on the server. Please correct me if I am wrong.
I am not intending to start a REST vs SOAP debate but I guess things are not that crystal clear anymore.
Any suggestions or guidelines on what to use where?
In my view ADO.Net data services is for creating restful services that are closely aligned with your domain model, that is the models themselves are published rather then say some form of DTO etc.
Using it for RPC style services seems like a bad fit, though unfortunately even some very basic features like being able to perform a filtered counts etc. aren't available which often means you'll end up using some RPC just to meet the requirements of your customers i.e. so you can display a paged grid etc.
WCF 3.5 pre-SP1 was a fairly weak RESTful platform, with SP1 things have improved in both Uri templates and with the availability of ATOMPub support, such that it's becoming more capable, but they don't really provide any elegant solution for supporting say JSON, XML, ATOM or even something more esoteric like payload like CSV simultaneously, short of having to make use of URL rewriting and different extension, method name munging etc. - rather then just selecting a serializer/deserializer based on the headers of the request.
With WCF it's still difficult to create services that work in a more a natural restful manor i.e. where resources include urls, and you can transition state by navigating through them - it's a little clunky - ADO.Net data services does this quite well with it's AtomPub support though.
My recommendation would be use web services where they're naturally are services and strong service boundaries being enforced, use ADO.Net Data services for rich web-style clients (websites, ajax, silverlight) where the composability of the url queries can save a lot of plumbing and your domain model is pretty basic... and roll your own REST layer (perhaps using an MVC framework as a starting point) if you need complete control over the information i.e. if you're publishing an API for other developers to consume on a social platform etc.
My 2ΓΈ worth!
Using WCF's rest binding is very valid when working with code that doesn't interact with a database at all. The HTTP verbs don't always have to go against a data provider.
Actually, there are options to filter and skip to get the page like feature among others.
See here: