For organizations still relying on older SOAP-based integrations in PeopleSoft, modern API management can feel like a massive undertaking. At BLUEPRINT 4D 2026, Curtis Hanson of King County demonstrated a practical, real-world approach to modernizing integrations using the PeopleSoft Application Services Framework (ASF).

The session, “Need some REST? Try ASF!,” walked attendees through how King County transitioned from SOAP services to REST-based APIs while simplifying deployment, improving readability with JSON, and aligning with centralized API management requirements. More importantly, Hanson showed that ASF is not just a technical feature buried inside PeopleTools — it can become a strategic modernization tool for organizations trying to make PeopleSoft integrations easier to manage, secure, and consume.

Why King County Moved Toward ASF

King County has been running PeopleSoft for more than 26 years across a broad range of services, including airports, courts, transit, wastewater treatment, and public safety operations. Hanson explained that the county’s Business Resource Center (BRC) manages multiple Oracle platforms, including PeopleSoft HCM, Oracle E-Business Suite, analytics tools, and Oracle Planning and Budgeting Cloud Service.

The push toward ASF was driven largely by enterprise API management requirements. The county standardized on Microsoft Entra for identity and access management, which introduced OAuth authentication and centralized API governance requirements. Existing SOAP services could technically still work, but they created friction.

Early experiments involved converting XML payloads into JSON through the API management layer itself. While functional, that approach introduced dependencies on the API management team every time a change was required. ASF changed that dynamic.

By using ASF alongside deployment pipelines into the county’s API Manager (APIM), the PeopleSoft team could independently deploy and manage APIs without relying on another department’s schedule or resources.

That independence became one of the biggest operational wins of the project.

Understanding ASF and REST in PeopleSoft

Hanson described REST as a more lightweight alternative to SOAP that works directly with HTTP rather than layering protocols on top of it. Within PeopleSoft, REST support lives inside Integration Broker through the REST Listening Connector.

ASF, introduced in PeopleTools 8.59, acts as a framework on top of Integration Broker that helps developers build RESTful APIs more cleanly and consistently. Instead of exposing large SOAP operations, APIs can be broken into resource-based structures that are more intuitive for consumers.

Hanson illustrated this with an employee example:

• /employees returns a collection of employee IDs
• /employees/{employeeId} returns one employee
• /employees/{employeeId}/balances returns balances for that employee
• /employees/{employeeId}/reportedtime returns time data

This resource-driven structure aligns with common REST API design patterns and produces JSON responses that are both compact and human readable.

One especially useful capability Hanson highlighted was HATEOAS (Hypermedia as the Engine of Application State). These embedded links allow APIs to expose discoverable related resources directly in responses, helping consumers navigate available data dynamically.

Why JSON and REST Matter

One recurring theme throughout the session was simplicity.

SOAP services often rely heavily on XML, which can become verbose and difficult to maintain. ASF-based REST services instead return JSON, dramatically reducing payload size and improving readability for developers.

That matters because many organizations consuming PeopleSoft data today are not necessarily PeopleSoft experts. Internal agencies, third-party applications, analytics tools, and cloud platforms increasingly expect lightweight REST APIs and JSON payloads.

Hanson emphasized that ASF also provides more semantically appropriate HTTP methods than SOAP. Developers can use:

• GET for retrieval
• POST for submissions
• PATCH for partial updates
• PUT for replacements
• DELETE for removals

SOAP, by comparison, typically relies almost exclusively on POST operations regardless of intent.

ASF additionally supports HTTP response codes, making APIs easier to troubleshoot and align with modern development standards.

Building REST APIs with ASF

One of the most valuable parts of the presentation was Hanson’s walkthrough of the ASF development process itself.

Application services begin with a service definition, which can function as either a provider or consumer. In practice, Hanson noted ASF is usually better suited for provider services.

From there, developers define:

• Root resources
• URI templates
• Parameters
• Methods
• Response states
• Application package behavior

The URI template system is particularly important because it defines how consumers interact with the API. ASF supports parameterized paths and query-style expansions that allow APIs to handle filtering and resource selection dynamically.

Hanson also stressed the importance of application packages in ASF. These packages define resource behavior and allow the framework to detect HTTP verbs programmatically. The framework routes requests based on URI templates and HTTP methods, helping developers consolidate multiple endpoints into a single service architecture.

The result is cleaner organization and fewer service operations overall.

Practical Lessons from the Demo

The live demo showcased a downloadable project containing APIs for operators and roles within PeopleSoft. The example demonstrated several practical ASF concepts, including:

• Collection endpoints
• Parameterized resources
• Query filtering
• Compound arrays
• Document-based responses
• Role and permission retrieval

One notable limitation Hanson discussed involved PeopleSoft documents. ASF wraps document payloads inside base parameter names, which can introduce extra structure developers may not want in a polished API design.

To improve the overall API development experience, the team adopted a design-first approach using APIDog. This tool simplified schema management, testing, and documentation generation significantly compared to managing PeopleSoft documents manually.

The benefits were substantial:

• Easier schema reuse
• Better testing workflows
• Generated OpenAPI specifications
• Automatic documentation creation
• Multi-language API examples
• Improved maintainability

Instead of manually documenting APIs, the tooling generated developer-friendly specifications almost automatically.

For organizations trying to modernize integration practices without dramatically increasing maintenance overhead, that capability alone could justify the effort.

Security and Governance Considerations

Security was another major focus during the audience Q&A.

King County uses OAuth through Microsoft Entra combined with API Manager-issued client IDs, client secrets, bearer tokens, and subscription validation. Behind the scenes, PeopleSoft itself still relies on tightly controlled service accounts with dedicated permission lists.

But the team went even further.

Rather than exposing all API endpoints universally, they implemented additional endpoint-level authorization using a custom PeopleSoft bolt-on using the ASF metadata. This allowed agencies to access only the resources they actually needed, reducing exposure to sensitive PII-related data.

That layered security model demonstrated a mature approach to API governance — particularly for public-sector organizations managing highly sensitive employee information.

A Modernization Strategy That Feels Achievable

One of the strongest takeaways from Hanson’s presentation was that API modernization does not necessarily require abandoning PeopleSoft or rebuilding integrations from scratch.

King County used ASF to modernize existing component-interface-based services incrementally, exposing cleaner REST endpoints while preserving core business logic underneath.

The organization gained:

• Simpler JSON payloads
• RESTful APIs
• OpenAPI documentation
• Centralized API management integration
• Reduced operational dependencies
• Better developer experience
• Improved governance controls

Perhaps most importantly, the session showed that PeopleSoft can still participate effectively in modern API ecosystems when organizations leverage the right tools and architectural patterns.

For PeopleSoft teams facing increasing pressure to modernize integrations without introducing unnecessary complexity, ASF may be one of the most underutilized tools already available inside the platform.

Want more?

Explore more content and resources to help you get the most from your Oracle investment:

• Visit the Quest Learn Library for blogs, how-to demos, and on-demand sessions.
• Connect with peers in one of our Quest PeopleSoft Community User Groups to swap stories, ask questions, and share tips with other users facing the same challenges.

Not a Quest member yet? Join today and tap into the ultimate Oracle customer network.