Hi,
I've come across a small hurdle with ERRest when dealing with CORS and HTTP
OPTIONS calls.
Background:
When using the addDefaultRoutes([some entity]) method in your
ERXRouteRequestHandler, one of the routes added is for the root entity when the
HTTP verb OPTIONS is called, usually by a browser or other client when cross
domain calls are employed.
So when, say, a GET is called for the index/search of an entity:
GET :: [rh key]/[Entity Name].json
the user agent or client might make an OPTIONS call first. This works fine --
when the correct headers are set of course, which is done in the
ERXRouteController class (unless you override it yourself).
Hurdle:
Sometimes though, one of my client apps may want to make an entity "show"
request straight up, no "root level" index or search:
GET :: [rh key]/[Entity Name]/[unique identifier].json?[params]
and the user agent quite rightly requests an OPTION call before this.
If you're using the addDefaultRoutes(..) convenience for that entity, or the
standard examples, that OPTIONS call will fail /return a 405, because the "non
root" route hasn't an Options path assigned.
One fix is to add a separate route when setting up your REST routes:
routeRequestHandler.addRoute(new ERXRoute(Foo.ENTITY_NAME, "Foo/{foo:Foo}",
ERXRoute.Method.Options, FooController.class, "options");
Has anyone come across this before, and is there a better way of dealing with
this case? Am I missing something in the way the "non-root" routes are created
with respect to cross domain/CORS calls and OPTIONS?
Thanks,
--
Matt
http://logicsquad.net/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
