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.

  • 3
    What do they want to know that's not provided by your API? Or, put differently, if there's something they need that's not in the API, maybe it belongs in the API.
    – Caleb
    Nov 30, 2012 at 19:05
  • Maybe they want to understand how you're storing data so they know how to best use the API. Maybe they don't need to see your schema, but they're just curious. Did they say why the need this, or did they just ask without explaining themselves? It's hard to say much more without knowing the details about the app, the API, and what these developers are trying to do. Nov 30, 2012 at 19:09
  • @Caleb This is what I would think, but they hadn't actually seen the documentation or perused the API at the point they asked.
    – ian
    Nov 30, 2012 at 19:18
  • 3
    @Iain: If they hadn't actually looked at the documentation yet, then maybe suggest they read it first, and then ask more specific schema-related questions that aren't addressed by the document. Maybe they just need some sample code that shows them how to use the API. Nov 30, 2012 at 19:23
  • 3
    @Iain: Alright, now it sounds like there is a communication breakdown somewhere more than anything else. Nov 30, 2012 at 20:15

3 Answers 3


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.)

  • Thanks for the reply, that's very helpful. I would mark it correct straight away (since you've agreed with me:) but I'll leave it open a little while and see if a contrary point of view is posted - though looking at the votes you're getting I doubt that will happen!
    – ian
    Nov 30, 2012 at 19:49

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.

  • 2
    As developer who has written APIs for mobile developers, I support this answer. While having knowledge of how the application behind the API works is useful to a mobile developer (who can then work with you to make your API better), the mobile app doesn't need anything more than public APIs.
    – Shauna
    Nov 30, 2012 at 21:09

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.