On 9/1/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
Simon Laws wrote:
> On 8/31/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>>
>> Oisin Hurley wrote:
>> >> I am not sure I understand the issue with create/delete (except if
>> >> PUT and DEL are disabled). Posting/putting to a URL that doesn't
>> >> exist yet to create that resource can be troubling. Is that the
>> >> issue? Are you looking for some kind of factory service pattern to
>> >> create resources?
>> >>
>> >> Or am I completely mis-understanding the issue you're describing
>> >> here? :)
>> >
>> > Apologies for not making the context clearer - however, you've got
the
>> > point: there needs to be either a resource factory, or a generic
>> > resource
>> > holder to process create/delete of resources. I think I was
attempting
>> > to say that a first cut would be ok to support just the GET/POST
>> (as the
>> > most pressing scenarios) and then the PUT/DEL and factory approach
>> could
>> > follow as a feature improvement.
>> >
>> > I will put up a wiki summary on this thread.
>> >
>> > cheers
>> > --oh
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > For additional commands, e-mail: [EMAIL PROTECTED]
>> >
>> >
>>
>> Yes, GET/POST first, PUT/DELETE later sounds reasonable to me.
>>
>> I've been struggling myself with the question on whether or not we need
>> some kind of resource holder/factory to create resources, and I'm now
>> starting to think that it really depends on how you view your
resources.
>>
>> Just a wild thought here...
>>
>> If you view your resources as objects, you'll probably say that you
need
>> a factory to do customerFactory->create("http://..../customer/1234";).
>> Then you'll say customers->get("http://..../customer/1234";) to retrieve
>> your customer object.
>>
>> If on the other hand you view the Web as a giant distributed file
>> system, then it's not so shocking to say:
>> customers->createFile("http://..../customer1234";);
>> customers->getFile("http://...../customer1234";);
>>
>> Thoughts?
>>
>> --
>> Jean-Sebastien
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> Hi Sebastien
>
> It's not clear that there is a difference between customers and
> customerFactory in your example. You are saying that there is some
> resource
> that causes the correct interpretation of PUT type requrests
> w.r.tgenerating/recording new resources that represent customers. This
> resource
> itself may, for example, represent the list of customers it has
> created in
> response to GET type requests. The relationship between Customers and
> Customer is not a wired relationship in the SCA sense but a resource
> relationship as dictated by the URLs used to represent endpoints.
>
> Regards
>
> Simon
>
Simon,
I agree with what you're saying. I think that we've now closed a loop :)
and that what you're saying is in line with the proposal at the bottom
of http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg06704.html
Then we raised the question of whether or not the create verb in
particular should be handled by a separate factory.
And in this last email I was trying to say that somebody coming with an
OO view would probably want that factory separate from the actual
resources (and that I was initially in that camp some time ago), but
that now I'm seeing these resources more like a file system (with no
separate factory) where:
customers.get("http://my.customer.database.com/customers/1234";); returns
an instance of the Customer XSD complex type for customer 1234
customers.put/post("http://my.customer.database.com/customers/1234";,
customerDataObject / or a diff) creates/updates customer 1234 with a
Customer instance.
customers.get("http://my.customer.database.com/customers/";) returns a
list of URIs to the customers.
Is that consistent with your view?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Yes, sorry, I wasn't very clear in my post. I'm not trying to go round the
loop again:-) Your summary is consistent with my view.
Assuming HTTP here I probably expect to get different results from
GET - http://my.customer.database.com/customers/ (get me all the
customer records?)
GET - http://my.customer.database.com/customers/1234 (get me one customer
record?)
I'm also probably asking for different things when I say
PUT - http://my.customer.database.com/customers/ (Create all the
customer records?)
PUT - http://my.customer.database.com/customers/1234 (Create one customer
record?)
In normal static HTTP land the semantics are the same in both cases as I'm
just GETing or PUTing data.
In our case what actually happens depends on both the verb and the identity.
So in mapping resource orientation to service orientation we may want to
give the service developer
more help in organizing the operations. Using Oisin's proposed annotations
we could say:
@Remotable
public interface CustomersService {
@RESTMethod(RestMethods.CREATE)
@RESTBaseURIContext("/customers")
String SetCustomerData()
{
If ( there is no customer ID on end of URI)
save all customers provided
else
save the data for customer identified by the URI
}
}
OR
@Remotable
public interface CustomersService {
@RESTMethod(RestMethods.CREATE)
@RESTBaseURIContext("/customers")
String GetCustomersData()
{
save all customers
}
@RESTMethod(RestMethods.CREATE)
@RESTBaseURIContext("/customers/*") ???? not sure about this but you
get the idea
String GetCustomerData()
{
save the data for customer identified by the URI
}
}
This is all I was saying really, i.e.
that the relationship between the "factory" and resource being created is
dictated by the URI and so the factory
is not explicitly visible. If you choose, in an SCA assembly, to have
separate services representing factory
functions and resource functions that may be fine (I think) but I'm not sure
that the client should care. They should have
access to some root URI and work from there. I said "I think" above because
if you do have separate services representing factory function and resource
function then I assume that
you would have to define two SCA "Services" also and the that host
environment would have to recognise the relationship
between the root URIs and dispatch accordingly. Mmm, sounds a little
complicated, maybe we should stick with mapping to a single service.
Regards
Simon
