RESTifying Procurement – Introduction

For the purpose of this series of postings I view Procurement as a collection of business processes (e.g. sourcing, ordering) and associated business documents (e.g. catalogue, order). The goal is to design the necessary kinds of services and media types to enable the procurement processes to be executed between software components using HTTP.

A practical way to start looking for necessary services is to think about the roles played by the parties participating in the processes (in a real scenario though, legacy systems are likely to influence the actual design).

REST is a client-server architectural style, employing the principle of separation of concerns and therefore we need to differentiate between client roles and server roles. If client and server roles are not separated correctly the application state that pertains to a given collaboration might in part be located on the client which would result in unnecessary complexity. (This issue should be addressed by a separate posting but I have written up some thoughts about it earlier).

Once the kinds of services are becoming clear the media types need to be designed. On the one hand these media types must be capable of expressing the domain information expressed by the various UBL documents, on the other hand, they must provide the proper linking semantics for the business process to advance. It is important to keep in mind that resource representations primarily transfer application state and not serialized domain objects.

Once the kinds of services and the media types are designed, I’ll take a look at the client programming model because one of the primary objectives of this exercise is to discuss how clients can cope with the evolvability granted to the server side by REST.

At the moment I really plan to provide an example implementation of the services to address associated development issues and make the whole example more practical. Let’s see how that works out though.

This morning I have already worked on defining a manageable subset of UBL catalogue documents to support the sourcing process. Stay tuned.

Leave a Reply