Actually there is a key concept that is missing here.
in REST
the example
<?xml version="1.0"?>
<p:Parts xmlns:p="http://www.parts-depot.com";
xmlns:xlink="http://www.w3.org/1999/xlink";>
<Part id="00345"
xlink:href="http://www.parts-depot.com/parts/00345"/>
<Part id="00346"
xlink:href="http://www.parts-depot.com/parts/00346"/>
<Part id="00347"
xlink:href="http://www.parts-depot.com/parts/00347"/>
<Part id="00348"
xlink:href="http://www.parts-depot.com/parts/00348"/>
</p:Parts>
provides a list of all possible links are provided.
so say for 27,000 parts this list could be very big.
then if you have option and variants, it could be a file that has
millions of links.
David E Jones sent the following on 1/7/2008 7:01 PM:
>
> On Jan 7, 2008, at 12:53 PM, Jacques Le Roux wrote:
>
>>> On Jan 7, 2008, at 5:14 AM, Jacques Le Roux wrote:
>>>
>>>> From: "David E Jones" <[EMAIL PROTECTED]>
>>>> REST is a more general architectural concept... what does it have to
>>>> do with this? In other words, I'm not quite sure what you mean by
>>>> "REST along with other ways".
>>>>
>>>> -David
>>>>
>>>> As BJ suggested in http://www.xfront.com/REST-Web-Services.html you
>>>> can create Web services in REST spirit. I know this have some
>>>> limitations (regarding object types arguments) but don't you think
>>>> it's a best practice to use this type of Web services before
>>>> thinking about using SOAP when you are in an heterogeneous
>>>> environment (ie not only Java using RMI) ?
>>>>
>>>> Jacques
>>>
>>> How would we implement a REST type web service interface?
>>
>> Using an HTTP service (ie using <ofbiz-ser> and XmlSerializer for
>> arguments). In my mind REST type web service and HTTP service are the
>> same, am'I wrong ?
>>
>> The idea is to avoid the SOAP overhead when it's not mandatory. At the
>> beginning I Googled for "rest vs soap" from which the question.
>
> I think the point of REST is that it is an architectural approach, and
> pretty much anything that transfers information according to the REST
> patterns qualifies, and I'd interpret those to even include SOAP if it
> is used appropriately (like request/response via HTTP) as SOAP is just
> an information container specific to remote invocation.
>
> Thanks for describing in more detail what you had in mind. Actually what
> you describe already exists, it is the "http" service runner
> (org.ofbiz.service.engine.HttpEngine).
>
> -David
>
