You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@esme.apache.org by Anne Kathrine Petterøe <yo...@gmail.com> on 2011/01/15 16:29:44 UTC
Our APIs
Moved on to the API page: http://cwiki.apache.org/confluence/display/ESME/API
We now have four APIs:
api - original REST-like API
api2 - streaming API
restapi - rest API
twitterapi - twitter API
or actually 5, we also have the jmx, but that's for a very specific use case..
I think we should simplify our APIs or at least it would be great if we could, because this scenario is very confusing for new users to Apache ESME. It is confusing even to me actually...
What are the current status on the different APIs?
Do we have any current clients which uses the original API?
/Anne
Re: Our APIs
Posted by Anne Kathrine Petterøe <yo...@gmail.com>.
I will move it somewhere else, I think it is good to keep as documentation, and update the main API page.
Thanks a million!
/Anne
On 16. jan. 2011, at 13.53, Ethan Jewett wrote:
> Well ... the RESTAPI page is about both apis (API and API2), which is
> causing a lot of confusion. I think we should just get rid of the page
> entirely, or indicate that it was a design discussion and is not valid
> documentation for either API. I'd be for deleting it, personally.
> Obviously it causes a lot of confusion :-)
>
> Ethan
>
> On Sun, Jan 16, 2011 at 1:36 PM, Anne Kathrine Petterøe
> <yo...@gmail.com> wrote:
>>> Here is my proposal: We keep the original API but we don't do work on
>>> it aside from security fixes. We add additional functionality to the
>>> API2 and the Twitter API going forward. We indicate that new clients
>>> should be developed using the API2. I should be able to support
>>> requests for new functionality in the API2 from client developers who
>>> are making use of it. I suggest we call them something like "API
>>> (deprecated)", "API2 (current)", and "Twitter-compatible API".
>>
>> Sounds good to me! Thanks for clarifying :-)
>>
>> Just to make sure I get this right...
>> https://cwiki.apache.org/confluence/display/ESME/API+2.0+-+Design
>> https://cwiki.apache.org/confluence/display/ESME/RESTAPI
>> These two wiki pages are talking about the same API right?
>>
>> Can I remove the column "Current (RPC)" on this page? https://cwiki.apache.org/confluence/display/ESME/RESTAPI
>> I think it is better if we use the page to document the API instead of comparing the two.
>>
>> /Anne
>>
>>
>> On 16. jan. 2011, at 13.18, Ethan Jewett wrote:
>>
>>> I think that "api" and "restapi" are the same thing, aren't they? API2
>>> is both more RESTful than the original (for whatever that is worth)
>>> and includes streaming functionality for a few endpoints with a Jira
>>> ticket in the backlog to implement streaming for more endpoints. It is
>>> not really accurate to call it a "streaming" API because it is a full
>>> API for the application that includes streaming functionality where
>>> appropriate.
>>>
>>> The https://cwiki.apache.org/confluence/display/ESME/RESTAPI page is
>>> actually a copy of the original API page
>>> https://cwiki.apache.org/confluence/display/ESME/Google+Code+API with
>>> further discussion of how to convert it to a more RESTful format. This
>>> eventually became the "API2"
>>>
>>> Confusing enough? ;-)
>>>
>>> Here is my proposal: We keep the original API but we don't do work on
>>> it aside from security fixes. We add additional functionality to the
>>> API2 and the Twitter API going forward. We indicate that new clients
>>> should be developed using the API2. I should be able to support
>>> requests for new functionality in the API2 from client developers who
>>> are making use of it. I suggest we call them something like "API
>>> (deprecated)", "API2 (current)", and "Twitter-compatible API".
>>>
>>> I think this actually tracks quite well with what we are already
>>> doing. How does that sound?
>>>
>>> Ethan
>>>
>>> On Sat, Jan 15, 2011 at 4:29 PM, Anne Kathrine Petterøe
>>> <yo...@gmail.com> wrote:
>>>> Moved on to the API page: http://cwiki.apache.org/confluence/display/ESME/API
>>>>
>>>> We now have four APIs:
>>>> api - original REST-like API
>>>> api2 - streaming API
>>>> restapi - rest API
>>>> twitterapi - twitter API
>>>>
>>>> or actually 5, we also have the jmx, but that's for a very specific use case..
>>>>
>>>> I think we should simplify our APIs or at least it would be great if we could, because this scenario is very confusing for new users to Apache ESME. It is confusing even to me actually...
>>>>
>>>> What are the current status on the different APIs?
>>>> Do we have any current clients which uses the original API?
>>>>
>>>> /Anne
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>
>>
Re: Our APIs
Posted by Ethan Jewett <es...@gmail.com>.
Well ... the RESTAPI page is about both apis (API and API2), which is
causing a lot of confusion. I think we should just get rid of the page
entirely, or indicate that it was a design discussion and is not valid
documentation for either API. I'd be for deleting it, personally.
Obviously it causes a lot of confusion :-)
Ethan
On Sun, Jan 16, 2011 at 1:36 PM, Anne Kathrine Petterøe
<yo...@gmail.com> wrote:
>> Here is my proposal: We keep the original API but we don't do work on
>> it aside from security fixes. We add additional functionality to the
>> API2 and the Twitter API going forward. We indicate that new clients
>> should be developed using the API2. I should be able to support
>> requests for new functionality in the API2 from client developers who
>> are making use of it. I suggest we call them something like "API
>> (deprecated)", "API2 (current)", and "Twitter-compatible API".
>
> Sounds good to me! Thanks for clarifying :-)
>
> Just to make sure I get this right...
> https://cwiki.apache.org/confluence/display/ESME/API+2.0+-+Design
> https://cwiki.apache.org/confluence/display/ESME/RESTAPI
> These two wiki pages are talking about the same API right?
>
> Can I remove the column "Current (RPC)" on this page? https://cwiki.apache.org/confluence/display/ESME/RESTAPI
> I think it is better if we use the page to document the API instead of comparing the two.
>
> /Anne
>
>
> On 16. jan. 2011, at 13.18, Ethan Jewett wrote:
>
>> I think that "api" and "restapi" are the same thing, aren't they? API2
>> is both more RESTful than the original (for whatever that is worth)
>> and includes streaming functionality for a few endpoints with a Jira
>> ticket in the backlog to implement streaming for more endpoints. It is
>> not really accurate to call it a "streaming" API because it is a full
>> API for the application that includes streaming functionality where
>> appropriate.
>>
>> The https://cwiki.apache.org/confluence/display/ESME/RESTAPI page is
>> actually a copy of the original API page
>> https://cwiki.apache.org/confluence/display/ESME/Google+Code+API with
>> further discussion of how to convert it to a more RESTful format. This
>> eventually became the "API2"
>>
>> Confusing enough? ;-)
>>
>> Here is my proposal: We keep the original API but we don't do work on
>> it aside from security fixes. We add additional functionality to the
>> API2 and the Twitter API going forward. We indicate that new clients
>> should be developed using the API2. I should be able to support
>> requests for new functionality in the API2 from client developers who
>> are making use of it. I suggest we call them something like "API
>> (deprecated)", "API2 (current)", and "Twitter-compatible API".
>>
>> I think this actually tracks quite well with what we are already
>> doing. How does that sound?
>>
>> Ethan
>>
>> On Sat, Jan 15, 2011 at 4:29 PM, Anne Kathrine Petterøe
>> <yo...@gmail.com> wrote:
>>> Moved on to the API page: http://cwiki.apache.org/confluence/display/ESME/API
>>>
>>> We now have four APIs:
>>> api - original REST-like API
>>> api2 - streaming API
>>> restapi - rest API
>>> twitterapi - twitter API
>>>
>>> or actually 5, we also have the jmx, but that's for a very specific use case..
>>>
>>> I think we should simplify our APIs or at least it would be great if we could, because this scenario is very confusing for new users to Apache ESME. It is confusing even to me actually...
>>>
>>> What are the current status on the different APIs?
>>> Do we have any current clients which uses the original API?
>>>
>>> /Anne
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>
>
Re: Our APIs
Posted by Anne Kathrine Petterøe <yo...@gmail.com>.
> Here is my proposal: We keep the original API but we don't do work on
> it aside from security fixes. We add additional functionality to the
> API2 and the Twitter API going forward. We indicate that new clients
> should be developed using the API2. I should be able to support
> requests for new functionality in the API2 from client developers who
> are making use of it. I suggest we call them something like "API
> (deprecated)", "API2 (current)", and "Twitter-compatible API".
Sounds good to me! Thanks for clarifying :-)
Just to make sure I get this right...
https://cwiki.apache.org/confluence/display/ESME/API+2.0+-+Design
https://cwiki.apache.org/confluence/display/ESME/RESTAPI
These two wiki pages are talking about the same API right?
Can I remove the column "Current (RPC)" on this page? https://cwiki.apache.org/confluence/display/ESME/RESTAPI
I think it is better if we use the page to document the API instead of comparing the two.
/Anne
On 16. jan. 2011, at 13.18, Ethan Jewett wrote:
> I think that "api" and "restapi" are the same thing, aren't they? API2
> is both more RESTful than the original (for whatever that is worth)
> and includes streaming functionality for a few endpoints with a Jira
> ticket in the backlog to implement streaming for more endpoints. It is
> not really accurate to call it a "streaming" API because it is a full
> API for the application that includes streaming functionality where
> appropriate.
>
> The https://cwiki.apache.org/confluence/display/ESME/RESTAPI page is
> actually a copy of the original API page
> https://cwiki.apache.org/confluence/display/ESME/Google+Code+API with
> further discussion of how to convert it to a more RESTful format. This
> eventually became the "API2"
>
> Confusing enough? ;-)
>
> Here is my proposal: We keep the original API but we don't do work on
> it aside from security fixes. We add additional functionality to the
> API2 and the Twitter API going forward. We indicate that new clients
> should be developed using the API2. I should be able to support
> requests for new functionality in the API2 from client developers who
> are making use of it. I suggest we call them something like "API
> (deprecated)", "API2 (current)", and "Twitter-compatible API".
>
> I think this actually tracks quite well with what we are already
> doing. How does that sound?
>
> Ethan
>
> On Sat, Jan 15, 2011 at 4:29 PM, Anne Kathrine Petterøe
> <yo...@gmail.com> wrote:
>> Moved on to the API page: http://cwiki.apache.org/confluence/display/ESME/API
>>
>> We now have four APIs:
>> api - original REST-like API
>> api2 - streaming API
>> restapi - rest API
>> twitterapi - twitter API
>>
>> or actually 5, we also have the jmx, but that's for a very specific use case..
>>
>> I think we should simplify our APIs or at least it would be great if we could, because this scenario is very confusing for new users to Apache ESME. It is confusing even to me actually...
>>
>> What are the current status on the different APIs?
>> Do we have any current clients which uses the original API?
>>
>> /Anne
>>
>>
>>
>>
>>
>>
>>
Re: Our APIs
Posted by Anne Kathrine Petterøe <yo...@gmail.com>.
Thanks, Ethan!
I will start cleaning up the 3 (!) pages we have on the Streaming/api2 API in the meantime.
/Anne
On 16. jan. 2011, at 19.04, Ethan Jewett wrote:
> Hi Anne,
>
> Lazyweb = smartweb :-)
>
> It is really close. I think it is missing documentation of the last
> development pass I made, which is 2 or 3 new methods, but everything
> else should be in good shape. I have made a "todo" for myself to go
> through this, update, and verify that everything is correct.
>
> Ethan
>
> On Sun, Jan 16, 2011 at 5:37 PM, Anne Kathrine Petterøe
> <yo...@gmail.com> wrote:
>> Ethan,
>>
>> I know this is a bit lazyweb, but you know the API2 best...
>> Could you please take a look at the table "Methods, Resources, and Descriptions" here https://cwiki.apache.org/confluence/display/ESME/API+2.0+-+Design and let me know if that is the current status of the API?
>>
>> Thanks,
>> Anne
>>
>>
>> On 16. jan. 2011, at 13.18, Ethan Jewett wrote:
>>
>>> I think that "api" and "restapi" are the same thing, aren't they? API2
>>> is both more RESTful than the original (for whatever that is worth)
>>> and includes streaming functionality for a few endpoints with a Jira
>>> ticket in the backlog to implement streaming for more endpoints. It is
>>> not really accurate to call it a "streaming" API because it is a full
>>> API for the application that includes streaming functionality where
>>> appropriate.
>>>
>>> The https://cwiki.apache.org/confluence/display/ESME/RESTAPI page is
>>> actually a copy of the original API page
>>> https://cwiki.apache.org/confluence/display/ESME/Google+Code+API with
>>> further discussion of how to convert it to a more RESTful format. This
>>> eventually became the "API2"
>>>
>>> Confusing enough? ;-)
>>>
>>> Here is my proposal: We keep the original API but we don't do work on
>>> it aside from security fixes. We add additional functionality to the
>>> API2 and the Twitter API going forward. We indicate that new clients
>>> should be developed using the API2. I should be able to support
>>> requests for new functionality in the API2 from client developers who
>>> are making use of it. I suggest we call them something like "API
>>> (deprecated)", "API2 (current)", and "Twitter-compatible API".
>>>
>>> I think this actually tracks quite well with what we are already
>>> doing. How does that sound?
>>>
>>> Ethan
>>>
>>> On Sat, Jan 15, 2011 at 4:29 PM, Anne Kathrine Petterøe
>>> <yo...@gmail.com> wrote:
>>>> Moved on to the API page: http://cwiki.apache.org/confluence/display/ESME/API
>>>>
>>>> We now have four APIs:
>>>> api - original REST-like API
>>>> api2 - streaming API
>>>> restapi - rest API
>>>> twitterapi - twitter API
>>>>
>>>> or actually 5, we also have the jmx, but that's for a very specific use case..
>>>>
>>>> I think we should simplify our APIs or at least it would be great if we could, because this scenario is very confusing for new users to Apache ESME. It is confusing even to me actually...
>>>>
>>>> What are the current status on the different APIs?
>>>> Do we have any current clients which uses the original API?
>>>>
>>>> /Anne
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>
>>
Re: Our APIs
Posted by Ethan Jewett <es...@gmail.com>.
Hi Anne,
Lazyweb = smartweb :-)
It is really close. I think it is missing documentation of the last
development pass I made, which is 2 or 3 new methods, but everything
else should be in good shape. I have made a "todo" for myself to go
through this, update, and verify that everything is correct.
Ethan
On Sun, Jan 16, 2011 at 5:37 PM, Anne Kathrine Petterøe
<yo...@gmail.com> wrote:
> Ethan,
>
> I know this is a bit lazyweb, but you know the API2 best...
> Could you please take a look at the table "Methods, Resources, and Descriptions" here https://cwiki.apache.org/confluence/display/ESME/API+2.0+-+Design and let me know if that is the current status of the API?
>
> Thanks,
> Anne
>
>
> On 16. jan. 2011, at 13.18, Ethan Jewett wrote:
>
>> I think that "api" and "restapi" are the same thing, aren't they? API2
>> is both more RESTful than the original (for whatever that is worth)
>> and includes streaming functionality for a few endpoints with a Jira
>> ticket in the backlog to implement streaming for more endpoints. It is
>> not really accurate to call it a "streaming" API because it is a full
>> API for the application that includes streaming functionality where
>> appropriate.
>>
>> The https://cwiki.apache.org/confluence/display/ESME/RESTAPI page is
>> actually a copy of the original API page
>> https://cwiki.apache.org/confluence/display/ESME/Google+Code+API with
>> further discussion of how to convert it to a more RESTful format. This
>> eventually became the "API2"
>>
>> Confusing enough? ;-)
>>
>> Here is my proposal: We keep the original API but we don't do work on
>> it aside from security fixes. We add additional functionality to the
>> API2 and the Twitter API going forward. We indicate that new clients
>> should be developed using the API2. I should be able to support
>> requests for new functionality in the API2 from client developers who
>> are making use of it. I suggest we call them something like "API
>> (deprecated)", "API2 (current)", and "Twitter-compatible API".
>>
>> I think this actually tracks quite well with what we are already
>> doing. How does that sound?
>>
>> Ethan
>>
>> On Sat, Jan 15, 2011 at 4:29 PM, Anne Kathrine Petterøe
>> <yo...@gmail.com> wrote:
>>> Moved on to the API page: http://cwiki.apache.org/confluence/display/ESME/API
>>>
>>> We now have four APIs:
>>> api - original REST-like API
>>> api2 - streaming API
>>> restapi - rest API
>>> twitterapi - twitter API
>>>
>>> or actually 5, we also have the jmx, but that's for a very specific use case..
>>>
>>> I think we should simplify our APIs or at least it would be great if we could, because this scenario is very confusing for new users to Apache ESME. It is confusing even to me actually...
>>>
>>> What are the current status on the different APIs?
>>> Do we have any current clients which uses the original API?
>>>
>>> /Anne
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>
>
Re: Our APIs
Posted by Anne Kathrine Petterøe <yo...@gmail.com>.
Ethan,
I know this is a bit lazyweb, but you know the API2 best...
Could you please take a look at the table "Methods, Resources, and Descriptions" here https://cwiki.apache.org/confluence/display/ESME/API+2.0+-+Design and let me know if that is the current status of the API?
Thanks,
Anne
On 16. jan. 2011, at 13.18, Ethan Jewett wrote:
> I think that "api" and "restapi" are the same thing, aren't they? API2
> is both more RESTful than the original (for whatever that is worth)
> and includes streaming functionality for a few endpoints with a Jira
> ticket in the backlog to implement streaming for more endpoints. It is
> not really accurate to call it a "streaming" API because it is a full
> API for the application that includes streaming functionality where
> appropriate.
>
> The https://cwiki.apache.org/confluence/display/ESME/RESTAPI page is
> actually a copy of the original API page
> https://cwiki.apache.org/confluence/display/ESME/Google+Code+API with
> further discussion of how to convert it to a more RESTful format. This
> eventually became the "API2"
>
> Confusing enough? ;-)
>
> Here is my proposal: We keep the original API but we don't do work on
> it aside from security fixes. We add additional functionality to the
> API2 and the Twitter API going forward. We indicate that new clients
> should be developed using the API2. I should be able to support
> requests for new functionality in the API2 from client developers who
> are making use of it. I suggest we call them something like "API
> (deprecated)", "API2 (current)", and "Twitter-compatible API".
>
> I think this actually tracks quite well with what we are already
> doing. How does that sound?
>
> Ethan
>
> On Sat, Jan 15, 2011 at 4:29 PM, Anne Kathrine Petterøe
> <yo...@gmail.com> wrote:
>> Moved on to the API page: http://cwiki.apache.org/confluence/display/ESME/API
>>
>> We now have four APIs:
>> api - original REST-like API
>> api2 - streaming API
>> restapi - rest API
>> twitterapi - twitter API
>>
>> or actually 5, we also have the jmx, but that's for a very specific use case..
>>
>> I think we should simplify our APIs or at least it would be great if we could, because this scenario is very confusing for new users to Apache ESME. It is confusing even to me actually...
>>
>> What are the current status on the different APIs?
>> Do we have any current clients which uses the original API?
>>
>> /Anne
>>
>>
>>
>>
>>
>>
>>
Re: Our APIs
Posted by Ethan Jewett <es...@gmail.com>.
I think that "api" and "restapi" are the same thing, aren't they? API2
is both more RESTful than the original (for whatever that is worth)
and includes streaming functionality for a few endpoints with a Jira
ticket in the backlog to implement streaming for more endpoints. It is
not really accurate to call it a "streaming" API because it is a full
API for the application that includes streaming functionality where
appropriate.
The https://cwiki.apache.org/confluence/display/ESME/RESTAPI page is
actually a copy of the original API page
https://cwiki.apache.org/confluence/display/ESME/Google+Code+API with
further discussion of how to convert it to a more RESTful format. This
eventually became the "API2"
Confusing enough? ;-)
Here is my proposal: We keep the original API but we don't do work on
it aside from security fixes. We add additional functionality to the
API2 and the Twitter API going forward. We indicate that new clients
should be developed using the API2. I should be able to support
requests for new functionality in the API2 from client developers who
are making use of it. I suggest we call them something like "API
(deprecated)", "API2 (current)", and "Twitter-compatible API".
I think this actually tracks quite well with what we are already
doing. How does that sound?
Ethan
On Sat, Jan 15, 2011 at 4:29 PM, Anne Kathrine Petterøe
<yo...@gmail.com> wrote:
> Moved on to the API page: http://cwiki.apache.org/confluence/display/ESME/API
>
> We now have four APIs:
> api - original REST-like API
> api2 - streaming API
> restapi - rest API
> twitterapi - twitter API
>
> or actually 5, we also have the jmx, but that's for a very specific use case..
>
> I think we should simplify our APIs or at least it would be great if we could, because this scenario is very confusing for new users to Apache ESME. It is confusing even to me actually...
>
> What are the current status on the different APIs?
> Do we have any current clients which uses the original API?
>
> /Anne
>
>
>
>
>
>
>
Re: Our APIs
Posted by Richard Hirsch <hi...@gmail.com>.
On Sat, Jan 15, 2011 at 4:29 PM, Anne Kathrine Petterøe
<yo...@gmail.com> wrote:
> Moved on to the API page: http://cwiki.apache.org/confluence/display/ESME/API
>
> We now have four APIs:
> api - original REST-like API
> api2 - streaming API
> restapi - rest API
> twitterapi - twitter API
>
> or actually 5, we also have the jmx, but that's for a very specific use case..
>
> I think we should simplify our APIs or at least it would be great if we could, because this scenario is very confusing for new users to Apache ESME. It is confusing even to me actually...
>
> What are the current status on the different APIs?
We probably have to make a decision if we are going to support the
original REST API.
> Do we have any current clients which uses the original API?
Most of the clients use the original API.
>
> /Anne
>
>
>
>
>
>
>