APIs with an Appetite

ABSTRACT

Dear KV, This may sound funny to you, but one of my co-workers recently called one of my designs fat. My project is to define a set of database APIs that will be used by all kinds of different front-end Web services to store and retrieve data. The problem is that a one-size-fits-all approach can't work because each customer of the system has different needs. Some are storing images, some are storing text, sound, video, and just about anything else you can imagine. In the current design each type of data has its own specific set of APIs to store, search, retrieve, and manipulate its own type of data. If I constrain the API too much, then some group won't be able to use it and will build its own local API. That means we will lose the advantages of having a central store for all different types of data. As it stands now, there are about 500 different API calls in the library. Is that too fat?

INDEX TERMS

Primary Classification:
  D. Software
  D.2 SOFTWARE ENGINEERING
        D.2.13 Reusable Software
            Subjects: Reusable libraries

Additional Classification:
  D. Software
  D.2 SOFTWARE ENGINEERING
        D.2.11 Software Architectures
      D.2.2 Design Tools and Techniques
          Subjects: Object-oriented design methods

General Terms:
Design