Context:
I have an existing Web API of the following form:
http://site/api/{area}?slicer1=alpha&slicer1=beta&starttime=sometime&endtime=sometime
It's implemented in ASP MVC. The API's function processes the parameters and feeds them into a SQL query. On success, it returns a IHttpActionResult with JSON data from SQL.
Note that the API lacks an entity model or entity relationship diagram. It's essentially just a wrapper around a SQL query.
Question:
Recently, I started learning about OData. It seems like OData is designed for the URL itself to control how data is filtered, as opposed to authoring a custom SQL query to filter.
Hence, I'd like an answer on whether my Web API could be converted to an OData API and, if so, what OData capabilities I'd need to do that (for instance, might OData v4 functions be useful)?
Clarifications:
I don't have any code written, nor am I asking for code as an answer.
I am looking to know what OData capabilities might enable my scenario (v4 functions, actions, etc...), or if OData and Web APIs are so different that my ask doesn't make sense.
Anticipating the "Why are you asking" this questions - I'm just interested in technically feasibility as a learning exercise.
You could switch to a OData API but if you have no entities, i.e. no IQueryable to query, you'd still have to do the SQL command generation by yourself. It's not too hard though - we did it in the project I'm working in.
You also have to ask yourself to what extent you want to switch to OData. For example, you could decide to just use its (type-safe) query-string parsing capabilities and from the parsed filter tree generate your own SQL (as mentioned above).
On the other hand, having a fully fledged OData API would also dictate the response format to comply to the standard. This would mean that you can start connecting to your API using OData aware tools (e.g. Excel, KendoUI Grid, etc.). I don't know if that would give you any benefit for your use-case.
Your question
what OData capabilities I'd need to do that
is not exactly clear to me. There are no OData capabilities that would help you to migrate from a Web API to an OData API. OData is just a set of standardized query (CRUD) and response formats. You can also be OData compliant by implementing all on your own using out-of-the-box Web API facilities but probably you'd want to use the Web API OData package.
The most important question for you is to ask yourself what advantage you'd have using OData.
Related
I've developed a .Net web application using the SOAP API (ReportingService2010) to list details on SSRS reports.
For the next step, I need to get some usage statistics such as which reports are accessed the most, which reports are accessed most frequently etc.
I know you can get some of this from the ExecutionLog table, but I'd like to avoid the SQL approach. Is there a way to get usage statistics like this directly through the SOAP API?
Thanks.
Nope. Best you can get from the stock API is snapshot/cache history information. You could, however, extend the existing API (pulling the information from ExecutionLogStorage). Even though you'd still be building the methods yourself, at least you could wrap them up nicely within the existing webservice.
I currently have a webforms asp.net using entity framework to do all the CRUD operations.
I need to create a public facing API for my website.
I need the following from an API:
Authentication of clients consuming the API
Usage Logging, to make sure there is no abuse etc
Throttling as an added extra to make sure one person doesn't overload the API.
Preferably the return data should be able to return in either JSON or XML, based on a flag the calling client uses.
I am looking for any guidance as the the most efficient way to create a public API to cater for these requirements. Suggested Books, Links, suggestions are all and any thing else are welcome.
Doing this in code is definitely do-able, but it's fairly involved for all those functions. An easier way is to use something like 3scale (http://www.3scale.net) which does all of this out of the box (you can issue API keys, rate limit them, get analytics for the API + create a developer portal). Setup is via a code library you drop into your system in general (libraries are here: (https://support.3scale.net/libraries) or there's an API or lastly set up Varnish as an API proxy in front of your application using this mod: https://github.com/3scale/libvmod-3scale/.
For the data return type, typically you would switch this by having .json, .xml in the API requests and handle this as a content type within the code.
Use WebAPI:
ASP.NET Web API is a framework that makes it easy to build HTTP
services that reach a broad range of clients, including browsers and
mobile devices. ASP.NET Web API is an ideal platform for building
RESTful applications on the .NET Framework.
http://blogs.msdn.com/b/henrikn/archive/2012/02/23/using-asp-net-web-api-with-asp-net-web-forms.aspx
http://www.asp.net/web-api/overview/hosting-aspnet-web-api/using-web-api-with-aspnet-web-forms
http://www.beletsky.net/2011/10/integrating-aspnet-mvc-into-legacy-web.html
I am trying to decide which way to go. I have a solution that needs to have a web service and a client side which is a windows phone 7 project. the WP7 project needs to communicate with the database through the WCF service.
I am a little bit confused as to which way i should choose to go, and what are the differences, advantages/disadvantages of regular WCF service file VS the WCF Data Service.
Which way will be easier to go with considering my wp7 app needs to run queries on some tables on the database, nothing too fancy.
Any explanation will be welcomed.
Thanks
WCF Data Services are great if you need CRUD and flexible query capabilities - they allow you to expose underlying data (e.g. via Entity Framework) and control security with a minimum of development effort, as a RESTful API, especially to AJAX and SPA type client front ends. (Also, note that WebAPI now also offers similar capabilities).
WCF Services are more for Formal "Service" and "Operation" integration capabilities, where there is a lot more business focus, e.g. rules, processing, workflow, etc.
e.g. WCF would be useful to Submit a Claim for Processing (custom / rich graph of data input and output), Trigger a Nightly batch job (void response), etc.
Also, you can combine both technologies, e.g. for a CQRS type architecture, by using Data Services for the Query, and WCF for the Command type capabilities.
I'm not really sure how to best word this. We have an ASP.NET web application with the backend services accessible over a WCF service layer. We need to add some reporting/dashboard type bits to the web application.
To make it scalable the data needed for the reporting needs to be calculated on the backend. I'm just wondering if there is a recommended way to pass this data around. It doesn't make much sense to have different service methods to get the different bits of data, it feels like it should be summarised already.
I had a look at WCF Data Services, but that seems more for retrieving full object trees. Maybe some sort of XML document so extra items can be added to the summary without needing service layer changes?
The data would be things like number of orders today, number of orders specific to the person running it, open orders outstanding etc.
Does anyone have any pointers?
Thanks for your time
You can look at something like ASP.NET Web API and use an XML Formatter for your data. You can use ViewModels to flatten your data and send over the wire to your web app to bind to grids or whatever you need to.
Basically you would get request (filters, keywords, etc) from your web app, send the parameters to your reporting back-end, retrieve the reporting data, map the values to your ViewModels and serialize them using Web API. Using Web API you can use all kinds of formatters for your data to XML, CSV and JSON to vCard, iCal, PDF, etc...
You can read more about it here: http://www.asp.net/web-api
I'm currently writing a web service using WCF in VB.NET.
Previous web services I wrote used ASMX but I wanted to learn WCF and so far it's going well. I actually prefer the way WCF does things.
One thing I miss however is the way that ASMX used to generate example SOAP requests and responses. It was like getting documentation for free.
Is there anyway to auto generate SOAP documentation for WCF?
If not, is there any way to generate it in a .NET page using the WSDL?
I guess this isn't supported by WCF in the same way it was for ASMX because WCF supports multiple endpoint types, not just SOAP web services (e.g. Net TCP, named pipes, etc).
SoapUI is a good little tool that can auto-generate SOAP messages from WSDL. Or you could create a small test client app, enable WCF tracing, and use the Service Trace Viewer Tool to view the messages that were sent.
I eventually found the answer. WCFExtras. The WCFExtras library allows you to document your API using XML comments and it reads those comments and inserts them into the WSDL as documentation comments. We then read this and generate HTML documentation using an application called TechWriter.