ERRest, CORS, and OPTIONS methods.
ERRest, CORS, and OPTIONS methods.
- Subject: ERRest, CORS, and OPTIONS methods.
- From: Matt Ness <email@hidden>
- Date: Sat, 02 Nov 2013 21:09:16 +1100
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@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden