BTW, for assets, in particular, there is already a GET metadata method, which is the same endpoint of the data itself, just with one more path compoenent /metadata/, if I remember correctly. This should be enough to know if the asset exists.

Doesn't address the issue of multiple UUIDs in one call vs one at a time.

On 4/1/2014 1:02 PM, Melanie wrote:
Because REST is cleaner and more modularized than RPC. Just compare
the code and you will see that. Efficiency is achieved by designing
the REST calls intelligently. The /asset/ endpoint for instance can
benefit from keep-alive because it supports HEAD/GET?POST so
multiple operations can reuse the connection.
The exists query is orthogonal to that and should be another request
endpoint.

Melanie

On 01/04/2014 21:56, Dahlia Trimble wrote:
Not sure about this particular application but keeping a connection open
can eliminate the need to instantiate a connection whenever a request is
made; a process that can make several round trips to multiple endpoints.


On Tue, Apr 1, 2014 at 12:52 PM, Mic Bowman <cmick...@gmail.com> wrote:

Do you really save much with a single request vs a keep alive on the
connection? HTTP connection overhead is likely much smaller than the
database operations... do you have a feel for how much we'll save with the
multiplexed call?

--mic



On Tue, Apr 1, 2014 at 12:49 PM, Oren Hurvitz <or...@kitely.com> wrote:

Re: why use POST instead of HEAD: because this lets me check the
existence of
many assets at once with a single HTTP request. The main use of the
AssetsExist call is with HGAssetGatherer, which knows the full list of
assets that it wants to send, so it's able to check all of them at once.



--
View this message in context:
http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119p7579127.html
Sent from the opensim-dev mailing list archive at Nabble.com.
_______________________________________________
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev


_______________________________________________
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev



_______________________________________________
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev



_______________________________________________
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Reply via email to