Re: Using ERRest but with extensions for non EOF back-end
Re: Using ERRest but with extensions for non EOF back-end
- Subject: Re: Using ERRest but with extensions for non EOF back-end
- From: "Brook, James" <email@hidden>
- Date: Fri, 15 Jan 2010 16:53:01 +0100
- Acceptlanguage: en-US
- Thread-topic: Using ERRest but with extensions for non EOF back-end
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 the top. There are no collisions in the end points, so we
hope to includes the EOEntity based one in both apps and extend on it
with the non EO stuff in just one of the apps. Hopefully the two
approaches will mix nicely with each other.
On 15 Jan 2010, at 13:19, Mike Schrag wrote:
> 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 change for an API and it
> would have caused problems with the D2Rest code, which requires
> entities. You COULD choose to mix the entity delegates and newer
> stuff, i think ... So you don't have to throw away the code you've
> already written for the entity delegates.
>
> ms
>
> On Jan 15, 2010, at 6:18 AM, Brook, James wrote:
>
>> 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 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 coding. Is there a straightforward path to
>>>> support
>>>> this, while making the RESTful API look seamless across the EOF and
>>>> the alternative back-end logic? I am concerned that we might have
>>>> to
>>>> make lots of adaptations to support this model.
>>>>
>>>> Any tips would be very much appreciated.
>>>>
>>>> --
>>>> James
>>>> _______________________________________________
>>>> 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
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>
>
_______________________________________________
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