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.
Posted in Identity, Identity Management, LDAP, Programming, SOA, SOAP
Tagged Idempotent, Identity, LDAP, Protocols, REST, SOAP
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.
Posted in Cloud computing, Google, Identity, Identity Management, Provisioning, SOAP, SPML, Standards
Tagged Identity, Identity Management, Provisioning, REST, SOAP, SPML
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.
Posted in SOAP
Tagged CISCO, Etch, SOAP
There was an interesting article on DSML recently (I ran across it in Dave Kearn’s IdM Journal). This is a useful summary, but unfortunately the article mixed in references to DSML v1 and DSML v2 in a way that will likely be confusing.
Just to clear this up, DSML v1 was a private vendor spec originally initiated by Bowstreet.com. DSML v2 is an OASIS Standard. There are some key differences DSML v1 only supported representing LDAP data and schema in XML but did not address web services. DSML v2 addressed web services. The two specifications are not compatible. The free DSML tools mentioned in the article are actually DSML v1 tools.
DSML v2 is supported by some of the main LDAP Vendors. DSML interfaces to LDAP servers include the Microsoft DSML Services for Windows (DSFW), the Netscape DSML Gateway, and the Novell DSML Support. Microsoft has also added DSML support to its .NET 2.0 Directory Services, although I haven’t had a chance to play around with it.
I had some peripheral involvement in the DSML v2 effort. While at Access360 I designed the new protocol for the enRole IdM server to communicate with the enRole provisioning agents. I create an XML/HTTPS protocol that was called the Directory Access Markup Language (DAML). DAML was basically a web services layer on top of DSML v1. It was actually pretty cutting edge at the time; the enRole system was using an XML/HTTPS protocol for provisioning while SOAP was still in development as standard. Access360 was of course acquired by IBM and the enRole system became the Tivoli Identity Manager (TIM). I don’t know if the DAML protocol is still being used, but you are likely to still see references to it in TIM documentation.
When the DSML v2 effort started with OASIS, the Access360 DAML spec was contributed as input to DSML v2, along with the Dir-XML spec from Novell. I had some initial involvement with the DSML v2 effort, but that ended when I left Access360 and joined OpenNetwork Technologies.
But I have always been a fan of DSML, which is why (for better or worse) SPML 1.0 was based on DSML v2.
(Mirrored from TalkBMC)
Identity, Identity Management, DSML, SPML, SOA, OASIS, Standards