AMS’s PowerBuilder-based client/server application, Procurement Desktop--Defense™, (PD²) is the basis of the Department of Defense’s Standard Procurement System. In developing the next generation of the AMS application, PD ^e , an n-tier, web-based J2EE system, AMS decided to provide a Public API to the business logic tier, and to extend delivery of XML-based documents and transactions to this API, leveraging past experience with XML in Government acquisition.

The Public API offers a comprehensive open programmatic interface suitable for integrating PD ^e with other enterprise applications. It’s goals are to move from a tightly coupled, multi-point integration approach and to meet the market need for integration choice—the power to choose how, and by whom, integration is accomplished. This paper presents an architectural model for the Public API. It describes components that accept API requests, carry out operations based on those requests, and provide appropriate responses.

The Public API is web services oriented, accessible to clients over standard protocols such as HTTP and SSL, and represents business entities using an XML vocabulary. Web services efforts heretofore have focused primarily on exposing RPC-like services, arguably unnecessarily complicating the task at hand. Rather than an RPC style, the Public API uses the Representational State Transfer, or REST, style, a formalization of the architecture of the Web. In REST, things of interest are made available as resources with specific URL’s, and manipulated using basic HTTP methods: POST, GET, PUT and DELETE. The REST style calls for a large number of resources and a small number of methods, and leverages HTTP infrastructure, including caches, global content delivery systems, firewalls, and server log analyzers.

Following the REST style, PD ^e entities such as purchase requests, awards and line items are, like Web pages, given URL’s. API clients will use HTTP methods to create, select, update and delete these entities, which are represented using an XML vocabulary based on the existing client/server PD² vocabulary, extended to incorporate PD ^e information and constructs described by this architecture and XML standards—XML Namespaces, XML Base, XLink, XPointer and XInclude. To interact with the Public API requires only a platform capable of TCP/IP communication (to send HTTP messages) and string processing (to process XML).

The Public API is internationalized, accepting documents with international content and producing Unicode content. It is firmly rooted in stable industry standards, using no home-grown or experimental alternatives. It is implemented on the J2EE platform, using the same J2EE version as PD ^e business logic—these two components can, though they need not, share a single execution environment, thereby increasing performance and reducing network traffic and easing system administration These constraints accelerate development, increase the potential for reuse of developers and resources across projects. The Public API authenticates and authorizes requests against the PD ^e user base and ACLs, transparently applying the PD ^e security model to Public API clients. Communications with the Public API are made confidential and safe through the use of HTTPS.

Internally, the PD ^e Public API is structured in two layers: a base layer and an application layer. The base layer provides building blocks that can technically be used to create API’s for other AMS J2EE applications. The application layer provides application-specific refinements to the base layer to create a specific application’s Public API, as with PD ^e .