Tag Archives: SOAP


The StormPath blog has an interesting article exploring HTTP PUT vs POST in REST based APIs for managing identity information. The article is interesting and worth reading, but misses the bigger picture. It points out that both HTTP PUT and POST can be used for sending updates in a REST API, but the HTTP spec mandates the HTTP PUT be idempotent. The idempotent requirement dictates that for an HTTP PUT, all values must be sent on the request, not just the ones being modified by the client.

Now I am sure idempotent PUT operations are important to people that design ways to update html documents. But I’m not in that business and neither are you. I am in the business of designing and enabling distributed identity systems, and in that business you never send a modification request that passes data you don’t need to modify. Simply put, you have to assume multiple concurrent updates to the backend data.

Put another way the article could simply have said “Never use HTTP PUT for data modification”. And herein lies the most important lesson of REST APIs: the REST mechanism is the means by which to build distributed systems, not an end to itself. The fact that you are using REST does not obviate the principals of basic distributed system design.

Oh, but it gets worse. Assuming your data model is attribute-value based, some of those attributes are going to be multi-valued attributes. Just as a client should only transmit the attributes that are modified, it should also only transmit the value modifications for multi-valued attributes.

That’s why LDAP Modify works as it does. One common mistake developers make using LDAP is not doing proper multi-valued attribute updates. Likewise your REST API will not only need to support partial record updates but partials attribute value updates.

Thoughts on SCIM

Now that SCIM 1.0 is final and SCIM 2.0 is starting I wanted to share my thoughts. First here is what I like about SCIM:

  • SCIM defined a standard schema in 1.0. I wish SPML had done the same. Not doing so was one of the biggest mistakes we made.
  • SCIM supports filtered and paged searches. That’s a must have in my book.
  • SCIM supports multi-value attributes with the proper modification semantics. You be surprised how many Identity APIs I have seen that don’t get the modification semantics right.
  • SCIM only did what it needed to do, nothing more.

So what don’t I like about SCIM? I don’t really care about the REST vs SOAP aspect. It’s not going to be widely used unless it’s wrapped in an API or toolset. So that’s a moot point. So I can’t really think of anything I don’t like.

But will SCIM be accepted where SPML was not? I don’t know, but I think there is a decent chance. I think announcing the IETF SCIM 2.0 effort so soon may be mistake as it may convince people to just ignore it until 2.0 comes out.

But ultimately the proof of standards is in adoption. For it to succeed it has to be both adopted by the cloud providers as a service and by IT as a client. Each of them wants the other to go first.

My biggest question is will the backers of SCIM implement it in their main product lines. Will SalesForce.com stand up a SCIM provisioning service? Will PingIdentity then add SCIM support to their SalesForce.com offering? We shall see.

Jackson Shaw has some great points to make about it here, but I didn’t really get the parrot reference. He points to this article about SCIM which also makes some great points.

It’s easier to push than be pulled

There is a lot of push vs pull provisioning discussion going on recently. Both models have a place but there is hard and fast rule you should consider. If your solution requires your customers to stand up a web service (SOAP or REST) you are going to be running uphill against a head wind. Customers see public web services as support and security costs they just don’t want to pay.

For most customers it’s far easier to have a system running in a data center that makes that makes web service requests to a provider than it is to stand up a service. Google, for one recognizes this. The Google Apps Directory Sync is often incorrectly cited as a “Pull Provisioning” technology when it is exactly the opposite. The sync software runs on the customer side, reads from the local directory and pushes to the Google Apps Provisioning Web Service.

A proper provisioning standard, regardless if it’s SOAP or REST, should support both push and pull (note that SPML supports both). But I really don’t see the pull model getting much traction for cloud based provisioning. Perhaps it will for provisioning internal applications.

A well loved joke is slain

One of my favorite jokes has been:

SOAP was really created by Cisco to create a need for more bandwidth.

Now Cisco has gone a killed that joke by pushing a SOAP replacement. (hat tip to Paul Madsen). Oh well, I will still have this one:

SOAP is the COBOL of XML messaging protocols.

I thought it was amusing that in the announcement Cisco positions Etch as a replacement for not only SOAP but CORBA and EJB as well. Saying that Etch will replace CORBA is kind of like saying VOIP will replace Telex. You are right in a way, but not directly.