So following REST web service best practice is not always a good thing, but of a controversial statement. That said I came across a situation that beautifully illustrated it.
I was recently asked for my opinion on a web solution that had to interact with customer data. The developers concerned implemented the functionality using REST web services and followed the principles to the letter. Except one of the services needed to locate a unique customer object. To do this the service enough customer details are provided in the URL to obtain a unique record.
So regardless of the security Implemented using strong SSL and payload encryption in the solution implementation we have just exposed every element in the network that can log URIs to DPA levels of security (not to mention information commissioner requests). That is before you consider man in the middle and packet URL attacks.
What to do, such sensitive web services need to be delivered without personal data in the URL, we could go via WSDL (but our use case points to REST being a better approach) or we follow the object creation pattern for REST (and pay the price of not caching the results on the web tier although if we are concerned about security then this isn’t such a bad thing and we can still get performance on the DB tier. Using the payload is probably the right thing to do.
Hi Phil,
Nice blog.
Presumably if the Customer ID was a System Identifier rather than a Customer Number with business meaning then DPA becomes a non issue. I’m assuming in the example you have given that was not the case.
Roger (who know who)
LikeLike
Bouncing purely system unique ids around wouldn’t be a DPA issue as the URL would not be sufficient for a customer to be identified. But If you don’t have that, then I’ll let you imagination suggestwhat might be in the URI query parameters
LikeLike