[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Exposing resources/services vs hiding implementationdetail

• To: Michael Champion <michaelc.champion@g...>
• Subject: Re: Exposing resources/services vs hiding implementationdetails
• From: Robert Koberg <rob@k...>
• Date: Tue, 05 Apr 2005 08:20:10 -0700
• Cc: xml-dev <xml-dev@l...>
• In-reply-to: <e3a5cb2c0504050804887b795@m...>
• References: <200504051139.j35BdXDR050954@s...> <42528FB5.7040300@p...> <e3a5cb2c0504050804887b795@m...>
• User-agent: Mozilla Thunderbird 1.0 (Macintosh/20041206)

Michael Champion wrote:
> On Apr 5, 2005 9:16 AM, Bill de hÓra <bill.dehora@p...> wrote:
> 
> 
>>If you decide to go the POST route, what you want to avoid  are exposing
>>controller URIs (all client requests go to one URI). At least give the
>>things of interest (the equivalent of your objects in your domain model
>>or your table rows in your physical data model) visible identity.
> 
> 
> Why " give things of interest (the equivalent of your objects in your
> domain model or your table rows in your physical data model) visible
> identity?"    That seems to violate the principle of information
> hiding that has been around since before OO.  It seems to be simply a
> Bad Idea to expose internal details in a world where slimeballs have
> proliferated  who would love to subvert your website for fun and/or
> profit.  Why not hide them behind a "controller URI" that accepts
> requests and gives them a going over with the polygraph and
> protocoscope, then routes them to whereever the system thinks they
> should be routed at this moment?
> 

I don't know the answer, but wouldn't it make security easier? You can 
protect an URI and reroute at a more external level before it goes into 
the system.

-Rob

• References:
  • RE: What Does SOAP/WS Do that A REST System Can't?
    • From: "Marc de Graauw" <marc@m...>
  • Re: What Does SOAP/WS Do that A REST System Can't?
    • From: Bill de hÓra <bill.dehora@p...>
  • Exposing resources/services vs hiding implementation details
    • From: Michael Champion <michaelc.champion@g...>

• Prev by Date: xsd:redefine issue using xsd:include
• Next by Date: RE: xsd:redefine issue using xsd:include
• Previous by thread: Exposing resources/services vs hiding implementation details
• Next by thread: Re: Exposing resources/services vs hiding implementationdetails
• Index(es):
  • Date
  • Thread