We're putting together a series of services using ASP.NET Web API. One proposal is to implement a "choreography" type design pattern where all clients connect to one endpoint and get routed based on the content of the GET and POST bodies. Another proposal is to just call each service directly.
What are the benefits of using a choreography-type design pattern?
Personally, I prefer one URL for all my services. It seems simpler but a single endpoint for simplicity isn't a valid argument.
Update -
I'm open to using headers for the routing portion. We're at "conceptual level" design at the moment and I guess I didn't think about using headers before posting. The body will be JSON. I am proposing this be implemented using ASP.NET Web API 4. Based on the header, the choreographer will route to the appropriate endpoint for processing.
If you are going to route only based on the content of the GET and POST bodies then I would say that you would be reinventing SOAP which is now considered heavyweight and legacy.
If you include the HTTP headers in this decision then you will be more RESTFul which is a good thing. You might also checkout the Web API which might help you with this design.
Related
I am developing a single page app running in desktop browser, tablet browser and maybe phone browser. I am return only JSON from my backend wether it is ASP.NET MVC or Web API.
When I think of Web API or read about it I always hear the words REST/RESTfull. Independently from what REST is I like some features about Web API which I have not in MVC (by default but maybe it can be implemented somehow but I dont want that extra effort...)
Return HttpStatus codes like 200 for GET or 201 when the Ressource is created. My single page app knows and reacts on this codes.
Return DTOs directly in the controller and c# classes are automatically serialized to json. With MVC this is not a one-liner. Not dealing with ActionResults.
Web API is very much designed about 'cool' urls/routing I will also have deep/complex routing on my client.
My Web API endpoints are just 'ajax callbacks' I do not need REST things like include a self.link in every retrieved ressource etc...
Of course I do not create/modify ressources on a Get request. But I already have been used to this style when I was doing MVC. So I like and will do many REST styles but not because of REST itself rather its common practice.
Should I really design great restfull API`s to use the Web API ? I do not know what is Microsofts recommendation about the Web API or wether they have really a guideline about it...
In my experience Web API has often been a great help, and rarely a hindrance. If you do it "their way," it saves you a lot of ugly work around serialization/routing/binding. If you don't want to do it "their way," you don't have to. You can extend the routing engine. You can implement your own serialization. You can return raw JSON where you see fit. Nothing in Web API forces you to follow the REST concept to a T (trust me I have seen this in action). I haven't heard this complaint before from anyone who has used it - I would suggest you give it a try and see just how far off it really is.
REST is not at all required to use Web API. In fact, it is quite easy to turn on and use session management as well.
In fact, while RESTful approaches have some real advantages, I wouldn't recommend going 100% RESTful. It is simply not possible to make them fully secure without using a third-party authentication provider. We built a fully RESTful prototype and explored many different mechanisms to secure the site. In the end, though, every one had one vulnerability or another (it helps to have a CISSP on staff). So I talked to one of the top security experts at Norton and he agreed that, yes, there is always a way to exploit a fully RESTful, standalone app. Symantec is apparently building a "wrapper" technology that gets around this but it was easier to either go with a third-party authentication provider or just go back to MS-based security using session cookies.
I want to build a Rails application that expose a RESTful web service used by a mobile application. I wanna create something maintainable and scalable, but I'm a little bit confused about best practises to achieve a good result.
First things first, API versioning. Over time my APIs will grow up and I want to keep them as smooth as possible. I've read this post: Best practices for API versioning? and I completely agree with it.
An excerpt of my routing strategy is:
/api/v1/ .. all sorts of controllers (api v1) ...
/api/v2/ .. (api v2) ..
/api/ .. controllers of the latest mainstream API
As a development strategy, I take advantage of JSON data formats, also to create new resources.
Another important aspect I'm afraid of is security: I cannot generate an authenticity token from the mobile APP, so I'm wondering how to protect the Rails API controllers.
Should I use standard HTTP authentication? Are there better ways to do that?
Last but not least, I'm trying to improve overall performances: remove unnecessary rack middlewares, inherit from ActionController::Metal and get rid of ActiveResource. Should I consider some pitfalls?
Any suggestion to build such a RESTful application will be appreciated.
You seems to be on right track, there are few things I want to mention:
Decide the input and output format. JSON is a faster choice but XML provides schema validation and more control. Chose depending on your need.
Use simple HTTP Basic authentication for security to start with. If you want more control, then introduces token based authentication such as OAUTH.
Make sure you use the plurals for the REST entities in URL. As plurals are good for a single or multiple entries fetch.
Decide about the synchronous and asynchronous nature of REST APIs. If an operation takes too long then make it asynchronous. Return a ref URL to user for polling as part of 202 Accepted response.
Hope it helps!
A fundamental idea in implementing a single page application with Knockout and Upshot is that most of the data will received from and sent to the server in JSON format using AJAX.
On the server, we will expose a number of endpoints (using perhaps WebAPI and the DbDataController) to respond to requests from Upshot. These endpoints may provide general queries for data such as lists of clients, previous orders, account information, etc.
Obviously, it is not desirable for one client to be able view another clients account information, previous orders, or other private data.
What strategies or approaches be used to secure queries (and data) which are being requested from upshot (or other mechanism) to the server? (In other words, how do we make sure a user only has access to his own data?)
Are the strategies the same or different than those used in a normal ASP.NET MVC application--namely use of the Authorize attribute?
This is probably a very simple question, but I am still not clear on all the differences between WebAPI controllers and normally ASP.NET MVC controllers.
Thank for your help!
A custom authorize attribute is one possible way to implement this requirement. The only difference with standard ASP.NET MVC controllers is that you derive from System.Web.Http.AuthorizeAttribute instead of System.Web.Mvc.AuthorizeAttribute.
I am quite familiar with ASP.NET MVC and know that a controller’s method can respond with XML and JSON apart from other things (i.e. behave like a restful webservice). I am just wondering whether I can make a controller method behave like a soap web service which responds with a SOAP XML response to a POST request? Maybe it is just question of responding with XML but this would be more like a restful web service. I want to avoid having to implement a separate web service project if possible. Any feedback would be very much appreciated. Thanks.
Christian
You don't need to implement a separate web service project. All you need is to add a WCF service endpoint (.svc file) to your current web project. Also you are saying that you expect SOAP response after a GET request which of course doesn't make much sense because in the SOAP specification requests should be POST.
I believe your thought is to create a single deployable MVC Web Application that can respond to both SOAP requests and RESTful requests (maybe even more?). I have thought about this myself, however there is no point in re-inventing WCF as it can do both without any additional programming. The ASP.Net MVC assemblies were not designed to function as a web service, and although it can, probably shouldn't be when other technologies exist that were designed specifically for that purpose.
I wanted to know, if say I had a MVC Application with some functionality and I want to provide this as a service to some of my clients. Do they need to go through coding and querying the XHTML data?(as it is represented in XHTML). I mean how do they generate proxy classes and use my methods? One of the ways is creating URI object but it seems there is still quite a bit of coding to be done in accessing that service(http://msdn.microsoft.com/en-us/magazine/dd943053.aspx).
So , how do i consume the service on Client Side and can I provide a XML?...I have just a simple method that gets user ID and returns details in the controller and respective view. I want to provide this as a service to my client and avoid lot of code.
If you are just exposing a bunch of XML from your various MVC controllers, then the only information clients have to go on is whatever you're doing to document your XML payload format and the URI scheme of your application.
If you want clients to be able to generate client proxies so that they can automatically consume your services, then they'll need some kind of meta data, in which case you should consider using WCF to create RESTful services which would allow for metadata generation and client proxy generation as well as just being able to do just "POX" access.
As the previous commenter said, if all you want to do is expose XML data from your MVC controller, there are a variety of ways this can be done - the easiest of which is just to have your View template render XML tags instead of HTML based on data stored in the ViewData dictionary. You can also very easily expose the underlying data as Json by returning a JsonResult instance from your controller method instead of View().