>> Suddenly the future is wide open....without *ANY* additional API
>> clutter.
>>
>> I seriously cannot see any reason why I ever should prefer
>> srv.AddCustomer().
> The reason why addCustomer is better than
> getCollection("Customer").add() (as a server side implementation
> API) is that it allows security concerns revolving around customers
> is localized to customer processing instead of having a huge
> collection of security constraints stuffed into a basic collection
> implementation. In particular, there is extra context present which
> can simplify how your security constraints are implemented. Also,
> it can make it more likely that you get the constraints correct,
> because there is not so much global context visible in the context
> of the add() operation.
I don't understand what you are saying. If I have three different
collections: one collection of vendors, and two collections of
customers, then in Atom, I can do a POST of a customer entity to
either of the customer collections, and/or a POST of a vendor entity
to the vendor collection.
Each of these three collections can implement any kind of security
and/or business rules that are appropriate to that specific
collection. How is this unstatisfactory compared to the "addCustomer"
approach?
-Patrick
------------------------ Yahoo! Groups Sponsor --------------------~-->
Yahoo! Groups gets a make over. See the new email design.
http://us.click.yahoo.com/XISQkA/lOaOAA/yQLSAA/NhFolB/TM
--------------------------------------------------------------------~->
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
