I have a site with a public API, and some mobile app developers have been brought in to produce an iPhone app for the site. They insist they need to see the database schema, but as I understand it, they should only need access to the documented public API.
Am I right? Is there something I’ve missed? I’ve told them that if there’s a feature missing or data they require I can extend the API so that they can access it. I thought a web service API held to much the same principles as OOP object API’s, in that the implementation details should be hidden as much as possible.
I’m not a mobile app developer so if there is something I don’t quite see then please let me know. Any insight or help will be much appreciated.
Update: The mobile team are part of a government funded advisory service for start ups. I’ve since found out that the project manager, who was the one pushing so hard to see the database and other internals, also works for a web development agency. I can’t say for sure what his reasons were for wanting to see this stuff, but considering he didn’t once give a valid technical reason I find this even more concerning than I did at the time.
8
They might want to see the schema so that they can replicate it on the mobile device. That will save them some work. Additionally, seeing the schema might prevent them from making wrong assumptions about how their data should be structured based on potentially-incomplete information about the database.
However, they should really come up with their own schema designed around the structure of the API data that’s designed to work within the constraints of the device. A SQL server typically has magnitudes more processing power and storage space than a phone, so why replicate the backend structure when the client device simply doesn’t have the capacity to cope with it? If they’re working on iOS and using CoreData, trying to think in a SQL-like way is potentially counter-productive as they’ll be dealing with a graph of hierarchical objects, not a collection of tables.
I’d argue that the developers should have no more knowledge of the backend than they can get from looking at the API and browsing its documentation. I agree with you entirely: the API hides implementation details that the mobile developers shouldn’t need to worry about. As a bonus, forcing them to work with the API will very quickly highlight any design problems and bugs.
(I’m a former backend/web frontend developer who switched to mobile work.)
1
Am I right? Is there something I’ve missed?
You’re right. There may or may not be something you’ve missed in the API, but there’s nothing peculiar about writing a mobile app that would require the developers to know what your database schema looks like. On the contrary, the more they rely on your public API and the less they rely on private implementation details like your database schema, the better. Ideally, they shouldn’t need to know anything about how your service works. The whole point of having a public Application Program Interface is to avoid apps needing to rely on private information.
All that said, it’s possible that your API doesn’t provide everything that’s necessary to implement whatever features the mobile app guys have in mind. Unless they’re really unreasonable, they should be able to appreciate the benefit (to them as well as to you) of writing to a public interface, so they should be willing to a) read and work with your API, and b) work with you to fix any holes in the API.
1
It sounds as if they just want to understand the domain model.
Perhaps if you provide them an entity relationship diagram in UML with all domain classes and their relationships then they will have a thorough understanding of everything they need to know. That is in fact all that they do need to know and an argument can be made about protecting sensitive trade secrets here as well.
I have seen such things requested through internal departments where clients of a web service API in another department demanded all of their project documentation before they started, and their reasoning was that this particular group of developers in charge of these web services had a notorious reputation for developing awful untested software. When other teams encountered problems with their poorly documented web services, they needed to understand as much about their system as possible so that the client group would be able to self diagnose and point the web service group into what they are doing wrong.
This mobile team probably isn’t satisfied with mocking your web services because they may have been burned in the past by previous web service developer groups that did a poor job. When their integration tests start failing against your environment, they won’t be able to tell their superiors that they have completed their tasks, so instead they probably want a full featured web service environment that they control so that they can run their integration tests successfully without needing your involvement.