Apps

Poll: How exposed would you leave your data?

The new .NET Data Services system allows you to expose your database via a REST service. Justin James says that putting raw data out there for a client to consume online goes against what he's learned. What are your thoughts on this topic?

I recently attended a presentation about the new .NET Data Services system, which allows you to expose your database via a REST service. This is apparently useful to AJAX applications that need to use HTTP for their calls but would rather put business logic 100% in the client than to just implement a Web Service with all of the logic baked into it.

Despite the ability to put security into the system, it goes against my entire career's worth of learning to just put your raw data out there for a client to consume on the Internet -- even if it is protected by a RESTful interface. What are your thoughts on this topic? Does it make sense, or is it lunacy?

J.Ja

About

Justin James is the Lead Architect for Conigent.

27 comments
Oleg F.
Oleg F.

I agree with Tony Hopkinson about tightly coupled code (I noticed your post after I had put this comment and now I cannot move it into your thread). Hard to change the data structure is a disadvantage of a tightly coupled code. When users consume raw data in the form of a web page made on the server side that data are hidden from the users. The web page is not very flexible for users but you can easily change the data structure. If the data are public it is no more easy to change its structure (name, type etc.) because already many users' software relies on the latest data structure. The more busyness logic is on the server side the more data is hidden. It's up to the publisher how invariant the data is expected to be.

Saurondor
Saurondor

I think the thing here is that HTTP so easy to utilize in these scenarios that it becomes commonplace. Using HTTP for REST doesn't mean you need to get HTML out of it. You can get XML, plain text or an image. Could we get a dynamically generated output from FTP? Sure I could. So raw data could be exposed through it too. But it would be like going back to the first days of static HTML. Reinventing the wheel to get a transport protocol for your information. I've used HTTP to expose data over the internet and I can see the benefits of doing so. It allows you to integrate clients which are not human and thus grow your system. It decouples the server from the client. As long as the client subscribes to the interface laid out, both systems can communicate. It allows for platform independence. For example one side can be done in php while the other in asp. It allows you to create local network client-server designs with a lot of ease and flexibility. Think point of sale for example. You can create a client that does the sales and talks directly to the database. Or you can create a client that talks over its own socket protocol to a server and gets information. This effectively decouples your client from the underlying database since the server handles that part of the business and data logic. But it still requires you to develop the protocol. Or you can use any of the HTTP solutions out there to provide information to your clients. This cuts down in time as you don't have to reinvent the wheel for every project.

Justin James
Justin James

Other than a Web app using JavaScript on the client side, why would I expose things via HTTP and not, say, ODBC? Other than (potentially) firewall issues? Any non-Web app will need to be planned for and installed anyways, so using ODBC (or a similar protocol) wouldn't be an issue. Talk about "reinventing the wheel". :) J.Ja

Tony Hopkinson
Tony Hopkinson

ODBC vs HTML isn't the real problem. Dumping your data into a clientside script, will almost certainly lead to a (select * From Table).asXML() type scenario. You then open up the possibility that you lose all control over what client side processing is done. A generic interface could be called from other interfaces and now you don't know what, who when or the why of any of the dependancies. Might as well just give them a connection string and full access to your database, the transport mechanism is a triviality. Other points ODBC = Old Dated Broken Crap One more use of HTTP and port 80 for yet more information to avoid setting up a decent mecahnism, might not be a big step further in thr wrong direction, but a step in it, it is, never the less.

Saurondor
Saurondor

It comes from the folks who developed Internet Explorer and Outlook. Nuf said

Tony Hopkinson
Tony Hopkinson

http://msdn.microsoft.com/en-us/library/dd728280.aspx Use a wizard to expose a database object... So select * from Table it is, then. You know it's going to happen, prediliction from cookie cutting numpties instead of people who know what they are doing, practically guarantees it. Auto-generated inefficient numpty designed, dataaware grids over the web. I can see it now.

Saurondor
Saurondor

Although you're exposing data through a web application. I don't see this as putting business logic in the presentation layer. The application that outputs this data has its own well defined data, business and presentation layers. The application's business layer is in charge of mapping the specific URLs to data retrieval and modification procedures. These procedures then return the data which is outputted through the applications presentation layer. Is the data presented in text format? in XML format? Excel format? an image? etc etc etc. It might in turn become a bigger application's business layer. But that doesn't mean you're putting business logic in the presentation layer. A simple way to demonstrate this is to allow the application to output the raw data in two different formats. One URL outputs XML and the other plain text. Clearly we are changing the output of the presentation layer, but the business logic behind it that is actually doing the data retrieval is still the same.

Tony Hopkinson
Tony Hopkinson

Expose backend data to the client for manipulation...

Saurondor
Saurondor

I don't get how you come up with business logic being found in the presentation layer. Could you explain please?

Tony Hopkinson
Tony Hopkinson

puting business logic in your presentation layer? How about doing it properly? My problem with the concept is it will be rapidly and massively abused. You've got to ask yourself why they want to go against a design basic, when you do answer that, no more needs to be said.

Saurondor
Saurondor

What would you suggest as an alternative?

Saurondor
Saurondor

a) Using ODBC requires the client application to be aware of the underlying database type and structure. Using HTTP isolates that from the client application. Thus changes in the database structure need not affect the client. b) What if the ODBC driver is proprietary or runs on a single platform? MS Access comes to mind. Using HTTP to access data allows my application to run on Linux and Mac in a transparent fashion. Licensing costs could also apply here. c) What if the ODBC driver requires a type of authentication not supported by the network topology. Active Directory and MS SQL server come to mind. This adds more to your afore mentioned firewall issues. d) Using HTTP allows you to expose methods through which data is accessed. This adds an extra layer of security and functionality. Client data is validated once again before the final commit which protects from rogue clients. e) I believe things like "get next available seat" are better handled by HTTP or similar web services than a direct database access. Using a web service over HTTP helps solve concurrency issues which are harder to implement with a clients accessing data directly. f) I've found performance to be way better when using an HTTP based web service than direct data access to the database. In one application involving RFID the time from chip read to label printing was greatly improved by using HTTP. This was a wireless implementation so when the signal got to low or vanished for a moment the usage of a direct database access required a lengthly login and session creation process. Whereas the HTTP implementation using an embedded web server was instantaneous for all practical purposes even with low signal levels. BTW the "server" was a GUI application running on a machine in the local network and it exposed data access through a port using HTTP. Since the application handled all the connection pooling to the database the response time to the clients was blazing fast. Overall I believe that using HTTP allows you to package data access functionality over an easy to use protocol. It provides direct data access which is easy to make "machine friendly" in a way that other programs can consume it for their needs. It decouples the client from the data storage. Said data storage can be made out of various storage methods (database, text files, RAM[as in current application status],etc) yet your only concern is the HTTP connection. And on top of these there are a lot of mature tools to create these types of implementations in very little time.

NickNielsen
NickNielsen

You can only mark posts as helpful in the Questions forum.

Oleg F.
Oleg F.

I have not found a link to do this.

Saurondor
Saurondor

Lets look at the basic steps: connecting, authentication, session creation, query, data transmission and possible connection closing. Once the web server starts up it sets up a connection pool. The web server is then connected to the database and ready to handle requests. The main benefit of connection pooling is having a set of available connections. This pool grows or shrinks depending on the load. Since the time required to start a new connection is larger than the time required to handle a request, applications benefit from this. So regardless of the authentication being done there's already a performance benefit. Then comes authentication. Lets say both take the same amount of time. But we know web servers can maintain authentication through a session over non persistent connections. But can the ODBC do that? If I loose my network connection for a period of time. HTTP will recover from that because that's the way HTTP works. But ODBC might take me back to square one and I'm back to getting a new connection. Then there's the whole issue of how much information needs to be transmitted to obtain a result. Do I require less traffic over HTTP than using ODBC? Honestly I don't know. So lets say this is the same for both. Finally there's the issue of closing the connection. Will I close a connection after each query? If so I'll have to restart with ODBC the next time I need data, but HTTP keeps my session. So we see that ODBC is also more demanding because it requires a persistent connection even when it isn't being used. Think server licenses. Five database "users" could service hundreds over the HTTP, but only five through ODBC. The web service can be seen as a database user proxy, so to speak.

Oleg F.
Oleg F.

You said that "direct database access required a lengthly login and session creation process". Did your embedded web server require any login? If yes why was it that fast compared to direct data access to the database? If not than could anyone access your database?

Tony Hopkinson
Tony Hopkinson

hosting / intranet technology being misused, again Aside from the security implications which most of us wouldn't put aside, what about the design ones. effectively business and presentation have been amalgamated, so now there's a massive dependancy and you are tightly coupled. Reminds me of the early days of activeX, you could get lots of adavantages from it, in an intranet, expose them to the outside world, and you create a massive hole in your security.

Oleg F.
Oleg F.

It is known that in some cases versioning can help bypass dependency on a data structure. May be if data structures are provided with their own versions (aside from .NET's own version) it could allow for future changes to the raw data structures?

Tony Hopkinson
Tony Hopkinson

datasets.... :( :( :( They are an absolute nightmare. You can certainly version the data structures to clear up what sort of fucntions they are meant to drive. Are you going to provide both though. How obvious is the change from one to the other. As a for instance. What if you provided Customer Order data, for various reports , number of ordrs gained, processed, completed, value etc, by customer and maybe some sort of categorisation. All the collation and aggragation done on the client. Then someone says this if furking slow, uses a hideous amount of bandwidth amd memory etc. So naturally having been introduced into the modern concept of client server, you do the aggregates and then pass them. How are you going to know that what you've provided, is what a myriad of client side consumers were trying to... Letting them do their own thing at the outset, large tin of worms.... Designed to fail.

Justin James
Justin James

You're right, I saw all of the pieces, but I never quite made the connection. It is *exactly* like ActiveX, other than the browser-specific implementation. Tightly couple code is right. Everyone is trying to turn the browser/server relationsip into an X11 or RPG or Terminal Services scnario, and it's rediculous. If that's what you want, just open X11 to the world and make a free X11 client for Windows. :) J.Ja

santeewelding
santeewelding

If so, I've wondered the same. Were you to open your topic a little wider, rather than to mention it back over your shoulder to a fellow, you could involve us all, and perhaps be surprised and gratified by the response. You, for instance, Justin, "put your raw data out there" the moment you speak.

NickNielsen
NickNielsen

of publishing proprietary information on the corporate web page? If it's on the web, somebody will find it and get access to it.

Justin James
Justin James

Well, you only expose the data that you want to. So no, you aren't exposing anything publically that you wouldn't give to a web visitor anyways. But it's basically giving the raw data out, and expecting the Web browser to process it and display it properly, and maybe change it (if appropriate). The more traditional way is to put all of that logic on the server, and have the browser simply make a basic request like "show me record #17" and the server doles out HTML with it all formatted. Hope that makes sense! J.Ja

NickNielsen
NickNielsen

wanting to buy a television and having to assemble it yourself from components...without the assembly diagrams.

Justin James
Justin James

More or less, yeah... either way, you get the same end result, but which makes more sense? J.Ja

Justin James
Justin James

It seems like as Web development develops as a field, the less I understand the thinking behind it. Am I completely out of touch? Am I becoming an "old man" who doesn't "get it"? Is the new crop of Web development techniques, like exposing the backend data over the Internet to clients via HTTP something which makes a lot of sense, but I'm too old-fashioned to see it? J.Ja

Zevel
Zevel

i am the junior admin of a company that supplies the building industry. Currently, we have a lot of potential for growth, as we have no e-commerce, but might start soon. i would gladly publish *some* of our data and pricing, but only to a limited number of clients, and only with full security. It would not be fair for a consumer in Nebraska to try and buy parts from us in Albany, NY, with published pricing, because our prices are better. Manufacturers of electrical products base costs across the country on things like volume, location, region, etc. While my company would have no problem selling items across the company, some manufacturers have signed contracts with us, and that could harm us. In a hearbeat, i would allow access to our personal clients, for financial purposes, but as far as parts of our db on the 'net? Maybe. In theory i would have a separate db, with only item information only, and nothing else. We have privileged data, as do most companies in this country.