[mapguide-users] MapGuide REST Extension

[Haris Kurtagic]

Currently we don't have any session based or temporary resources. We did
discussed that something in that direction could be done. Perhaps to
store complex URI to be reused too.

What MG REST extension supports now is that you can pass in query filter
not only geometry but also URI which represent that geometry ( that
resource).
In that way you can construct query which would return parcels under
building without sending building geometry but only URI representing
that building.

e.g. \REST\parcel\.html?bbox=http:\\...\rest\building\3 would return
parcels under bbox of building with id 3

btw, in this case parcels and buildings can be even served on different
servers.

Haris

-----Original Message-----
From: Jason Birch [mailto:Jason.Birch at nanaimo.ca] 
Sent: Wednesday, February 04, 2009 8:20 PM
To: MapGuide Users Mail List
Subject: RE: [mapguide-users] MapGuide REST Extension

Not sure why you would want to pass those features as a GET?

Are you maybe talking about selection or buffering by a user-defined
polygon?  If so, then the correct pattern would be to post that feature
to a session-based resource, and then reference that resource when doing
the selection.

Hmm.  I don't think that the framework currently supports accessing
session-based resources, but that's certainly something to think about.
Haris, do you have any insight into this?

The other option would be to send a POST with a "method" override in
either the HTTP headers or as a parameter.  Doing this breaks REST
design philosophy, and I wouldn't be all that happy to see it as a
primary access method, but many frameworks allow it.

Jason



-----Original Message-----
From: GordonL
Subject: Re: [mapguide-users] MapGuide REST Extension

the REST extension looks really promising.  I particularly like the
"code-free" aspect to extract attributes and coordinates of the
features.

Have  you found it limiting due to the GET limitations.  For example, I
often have features with thousands of vertices, and it would be
difficult
passing those features as a GET...