Thank you Mike. I hadn't seen the route controller approach until you
mentioned it. I think it's perfect for our needs - brilliant! We were
already working on the idea that we would have two separate API apps
because one part is mission critical and the other is a less important
layer over
Pretty sure you can't do this ... I think the entity delegate stuff is entirely
EOEntity-baed. When I made the newer route controller approach, support for
non-entity objects was part of the requirements for it. I started to backport
it to the entity delegates, but it was just too big of a chang
The existing API uses the entity delegate API.
On 14 Jan 2010, at 17:38, Mike Schrag wrote:
> are you use the entity delegate api or the route controller api?
>
> On Jan 14, 2010, at 11:36 AM, Brook, James wrote:
>
>> We have a WebObjects application that uses the ERRest framework to
>> provide a
are you use the entity delegate api or the route controller api?
On Jan 14, 2010, at 11:36 AM, Brook, James wrote:
> We have a WebObjects application that uses the ERRest framework to
> provide a RESTful API over our EOModel. We now want to extend the API
> to cover some other legacy back-off
We have a WebObjects application that uses the ERRest framework to
provide a RESTful API over our EOModel. We now want to extend the API
to cover some other legacy back-office services and persistence
mechanisms as well. The plan is to use fairly plain Java objects and
perhaps key value cod
