Contents

Is REST a Good Fit for PeopleSoft?

REST can be somewhat of a religion. In “pure” REST thinking, you design granular APIs that map cleanly to resources—potentially down to the table or even field level. This works beautifully when you have a bespoke application that you’ve designed from the ground up with APIs in mind. This results in API clients being able to interact with individual resources directly, using HTTP verbs like GET, POST, PUT, and DELETE in a straightforward manner. However, it can lead to complex designs with many endpoints and an API client having to manage multiple calls to achieve a single business operation.

However, when you’re exposing delivered PeopleSoft functionality as REST services, you cannot apply this pure REST thinking. Let me explain why.

The REST Philosophy

In the purest form of REST, your API design follows these principles:

  • URLs map to individual resources (e.g., /courses/101, /courses/101/attributes/5)
  • CRUD operations map directly to HTTP verbs (GET, POST, PUT, DELETE)
  • Resources are granular—you can interact with each entity independently
  • You can DELETE a child record by hitting its specific URL

This model makes perfect sense for modern applications that were designed with a “backend for frontend” architecture or built specifically as API-first systems. Many cloud-native applications work this way.

PeopleSoft was NOT designed this way.

Why Pure REST Doesn’t Fit PeopleSoft

PeopleSoft’s Component-Centric Reality

If you understand how PeopleSoft is structured, everything revolves around the data entry component. (A component means something very specific on the PeopleSoft development platform. Do not apply a generic understanding of that term from other contexts.) This is driven by the User Interface that the developers created to maintain data.

That component encapsulates the database commit, business logic, contains several parent-child relationships bundled together.

Key points about this architecture:

  • The component is the unit of work, not individual tables
  • The component encapsulates the database commit—you can’t commit child records independently. They are committed as part of the parent component transaction.
  • Parent-child relationships often go 3 levels deep
  • Business logic is tied to the component and its underlying pages
  • Effective dating and other PeopleSoft-specific concepts complicate direct table manipulation
  • If you are just updating a child table, you may need to provide context from the parent record.

Course Catalog Example

Let’s take real example of a data entry component in PeopleSoft Campus Solutions where you define the Course Catalog. This component allows users to create and maintain course records, including attributes, topics, equivalents, and other related data. This component is effective dated and has multiple child tables.

Curriculum Management → Course Catalog → Course Catalog

The tables behind this component have this parent-child relationship:

  • CRSE_CATALOG
    • CRSE_OFFER
    • CRSE_EQUIV_TBL
    • CRSE_TOPICS
    • CRSE_ATTRIBUTES
    • CRSE_COMPONENT
      • CRSE_ATTENDANCE
      • CMPNT_CHRSTC
    • SSR_CRS_MILESTN

If you were to design pure REST APIs for this component, you might think to create endpoints like:- GET /courses/{course_id}

  • POST /courses/{course_id}/attributes
  • DELETE /courses/{course_id}/attributes/{attribute_id}
  • PUT /courses/{course_id}/topics/{topic_id}
  • DELETE /courses/{course_id}/equivalents/{equiv_id}

However, this approach runs into several problems:

  • In that structure there is no way to reference the parent table context that is required to make changes to child records. (Effective date, for example, lives on the parent record.)
  • The parent table might need to have certain fields included in the payload to satisfy business logic or validation rules.
  • The component is structured for making sure that all related records are committed together when creating or updating a course. If a child record is deleted independently, it can violate data integrity rules.

The Effective Date Problem

In PeopleSoft, child records are often effective-dated, and the effective date typically lives on a parent record. You can’t simply issue a DELETE to remove a course attribute because:

  1. The attribute row is tied to an effective-dated parent
  2. “Deleting” the attribute often means posting an update that marks it as inactive or removes it from a specific effective-dated row
  3. You need to include information about the parent record (which carries the effective date context) in your request

What seems like it should be a simple DELETE /courses/101/attributes/5 actually requires a POST to the parent with the full context of what you’re changing.

The Commit Boundary Problem

The component controls when and how data commits to the database. If you have a component with three levels of parent-child relationships, the business logic at the higher levels may prevent you from making certain changes at the lower levels.

Creating an API to delete a third-level child record doesn’t really make sense because the PeopleSoft component might have validation or business rules at the first or second level that would prevent that commit. The component is designed to enforce data integrity across all its records together.

PeopleSoft Was Not Designed for This

There’s a lot of nuance here, and you have to have a true understanding of working with PeopleSoft to appreciate it. Most of PeopleSoft was not really designed to be integrated with—it wasn’t originally built with external systems in mind.

Technologies were introduced later to allow integration (like Component Interfaces and Integration Broker), but as soon as you start trying to apply enterprise integration patterns that you might see in modern systems, you’ll run into problems. PeopleSoft was designed as a monolith with the PeopleSoft UI being front and center in controlling all database transactions and data integrity. You have to meet PeopleSoft where it is, not where you want it to be.

A Practical Approach: Component-Aligned APIs

So what should you do instead? Structure your APIs around the data entry component that’s backing the functionality.

One API Per Component

My recommendation is to have one API per user interface component. This means:

  • If you have a configuration table for departments, you have one API for that component
  • Every table involved in that component can potentially be updated via that single API
  • For something like the Course Catalog, you have one API that maps to the Course Catalog component

Yes, the payloads will be larger than pure REST would suggest. But that’s how PeopleSoft commits data—the entire component’s data is part of one transaction.

Structure Around the UI, Not Tables

Instead of this (Pure REST) Do this (PeopleSoft-aligned)
/courses/{id}/attributes/{attr_id} DELETE /courses/{id} POST with attributes in payload
Separate endpoints per child table Single endpoint per component
Granular field-level updates Component-level updates with all relevant data

What This Means in Practice

  • Department configuration: One API for the department component; any table in that component can be updated through it
  • Course Catalog: One API covering all related records; any fields that can be updated are exposed in that API’s payload
  • Field-level control: If there are fields you don’t want external systems to update, you can handle that in the PeopleCode by ignoring those fields or simply not exposing them in your API documentation

Summary

A strict definition of REST is not a good fit for PeopleSoft because of how the system is architected. Instead of fighting the architecture:

  • Structure APIs around the data entry component, not individual database tables
  • Accept that payloads will be larger—that’s the nature of component-based transactions
  • Map one API to one UI component—this aligns with how PeopleSoft manages database commits
  • Work with the architecture, not against it—trying to force granular REST patterns will cause more problems than it solves

The sooner you accept that PeopleSoft REST services won’t look like textbook REST examples, the more successful your integrations will be.

Author Info
Chris Malek

Chris Malek s a PeopleTools® Technical Consultant with over two decades of experience working on PeopleSoft enterprise software projects. He is available for consulting engagements.

Work with Chris
Looking for pain-free PeopleSoft web services? 😀
PeopleSoft Simple Web Services (SWS)

Introducing a small but powerful PeopleSoft bolt-on that makes web services very easy. If you have a SQL statement, you can turn that into a web service in PeopleSoft in a few minutes.

Read More & Purchase