headers
Greg Young | 6 Feb 14:36
Picon
Gravatar

atom pub/high usage

 

Its pretty well known how to do a quick pub/sub with atom pub. If we
get loads and loads of consumers though it might be beneficial to say
hang a http connection and push results down the pipe in near real
time as opposed to polling (performance optimization only). This can
be done in a generic way, does anyone happen to know of a system that
just does that out of the box as opposed to building it?

--
Le doute n'est pas une condition agréable, mais la certitude est absurde.

__._,_.___
Recent Activity:
.

__,_._,___
Permalink | Reply | 8 comments |
headers
Jan Algermissen | 6 Feb 14:48

Re: atom pub/high usage


On Feb 6, 2012, at 2:36 PM, Greg Young wrote:

> Its pretty well known how to do a quick pub/sub with atom pub. If we
> get loads and loads of consumers though it might be beneficial to say
> hang a http connection

Huh? Are you saying, you want to switch from polling to push when number of users grow?

I'd suggest that, the more number of users you have, the less is push a good architectural choice. Better to
make use of HTTP caching to decrease umber of requests that actually hit your backend.

Look at archived feeds for this purpose <http://tools.ietf.org/html/rfc5005> or check out
<http://roy.gbiv.com/untangled/2008/paper-tigers-and-hidden-dragons> which I think is indeed a
very practical solution despite its 'esoteric' appeal at first glance :-)

If you feel you must use push, then there are solutions already such as XMPP.

Jan

> and push results down the pipe in near real
> time as opposed to polling (performance optimization only). This can
> be done in a generic way, does anyone happen to know of a system that
> just does that out of the box as opposed to building it?
> 
> -- 
> Le doute n'est pas une condition agréable, mais la certitude est absurde.
> 

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/rest-discuss/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/rest-discuss/join
    (Yahoo! ID required)

<*> To change settings via email:
    rest-discuss-digest <at> yahoogroups.com 
    rest-discuss-fullfeatured <at> yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    rest-discuss-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
Permalink | Reply | 7 comments |
headers
Greg Young | 6 Feb 14:51
Picon
Gravatar

Re: atom pub/high usage

There is good reason to switch to push as FREQUENCY of messages gets
higher. Try polling the twitter stream.

On Mon, Feb 6, 2012 at 8:48 AM, Jan Algermissen
<jan.algermissen <at> nordsc.com> wrote:
>
> On Feb 6, 2012, at 2:36 PM, Greg Young wrote:
>
>> Its pretty well known how to do a quick pub/sub with atom pub. If we
>> get loads and loads of consumers though it might be beneficial to say
>> hang a http connection
>
> Huh? Are you saying, you want to switch from polling to push when number of users grow?
>
> I'd suggest that, the more number of users you have, the less is push a good architectural choice. Better to
make use of HTTP caching to decrease umber of requests that actually hit your backend.
>
> Look at archived feeds for this purpose <http://tools.ietf.org/html/rfc5005> or check out
<http://roy.gbiv.com/untangled/2008/paper-tigers-and-hidden-dragons> which I think is indeed a
very practical solution despite its 'esoteric' appeal at first glance :-)
>
> If you feel you must use push, then there are solutions already such as XMPP.
>
>
> Jan
>
>
>> and push results down the pipe in near real
>> time as opposed to polling (performance optimization only). This can
>> be done in a generic way, does anyone happen to know of a system that
>> just does that out of the box as opposed to building it?
>>
>> --
>> Le doute n'est pas une condition agréable, mais la certitude est absurde.
>> 
>

-- 
Le doute n'est pas une condition agréable, mais la certitude est absurde.

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/rest-discuss/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/rest-discuss/join
    (Yahoo! ID required)

<*> To change settings via email:
    rest-discuss-digest <at> yahoogroups.com 
    rest-discuss-fullfeatured <at> yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    rest-discuss-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
Permalink | Reply | 6 comments |
headers
Greg Young | 6 Feb 14:52
Picon
Gravatar

Re: atom pub/high usage

My bad for not being clear in the original post.

On Mon, Feb 6, 2012 at 8:51 AM, Greg Young <gregoryyoung1 <at> gmail.com> wrote:
> There is good reason to switch to push as FREQUENCY of messages gets
> higher. Try polling the twitter stream.
>
> On Mon, Feb 6, 2012 at 8:48 AM, Jan Algermissen
> <jan.algermissen <at> nordsc.com> wrote:
>>
>> On Feb 6, 2012, at 2:36 PM, Greg Young wrote:
>>
>>> Its pretty well known how to do a quick pub/sub with atom pub. If we
>>> get loads and loads of consumers though it might be beneficial to say
>>> hang a http connection
>>
>> Huh? Are you saying, you want to switch from polling to push when number of users grow?
>>
>> I'd suggest that, the more number of users you have, the less is push a good architectural choice. Better
to make use of HTTP caching to decrease umber of requests that actually hit your backend.
>>
>> Look at archived feeds for this purpose <http://tools.ietf.org/html/rfc5005> or check out
<http://roy.gbiv.com/untangled/2008/paper-tigers-and-hidden-dragons> which I think is indeed a
very practical solution despite its 'esoteric' appeal at first glance :-)
>>
>> If you feel you must use push, then there are solutions already such as XMPP.
>>
>>
>> Jan
>>
>>
>>> and push results down the pipe in near real
>>> time as opposed to polling (performance optimization only). This can
>>> be done in a generic way, does anyone happen to know of a system that
>>> just does that out of the box as opposed to building it?
>>>
>>> --
>>> Le doute n'est pas une condition agréable, mais la certitude est absurde.
>>> 
>>
>
>
>
> --
> Le doute n'est pas une condition agréable, mais la certitude est absurde.

-- 
Le doute n'est pas une condition agréable, mais la certitude est absurde.

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/rest-discuss/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/rest-discuss/join
    (Yahoo! ID required)

<*> To change settings via email:
    rest-discuss-digest <at> yahoogroups.com 
    rest-discuss-fullfeatured <at> yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    rest-discuss-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
Permalink | Reply | 4 comments |
headers
Thomas Koch | 6 Feb 14:54
Picon
Gravatar

(java) rest framework with programmable dispatcher?

 

Hi,

I'm searching a java rest framework or JAX-RS implementation that allows me to
configure the dispatcher at runtime through an API. In JAX-RS it is only
possible to do the configuration with <at> Path and <at> HttpMethod annotations or by
effectively building your own dispatcher.

I'm searching for:

dispatcher.addResource("/my/{path}", Resource.class) or
dispatcher.addResource("/2nd/path", resourceHandlerFactory)

Thank you!
also posted at StackOverflow, if you like to collect points:
http://stackoverflow.com/questions/9161002/java-rest-framework-with-
programmable-dispatcher

Thomas Koch, http://www.koch.ro

__._,_.___
Recent Activity:
.

__,_._,___
Permalink | Reply | 1 comment |
headers
Jan Algermissen | 6 Feb 16:01

Re: atom pub/high usage

 


On Feb 6, 2012, at 2:51 PM, Greg Young wrote:

> There is good reason to switch to push as FREQUENCY of messages gets
> higher. Try polling the twitter stream.

Well, try pushing the Twitter stream to zillions of clients :-)

What I was referring to is to split the stream in archived (==static) pages that are then cacheable.

Jan

>
> On Mon, Feb 6, 2012 at 8:48 AM, Jan Algermissen
> <jan.algermissen <at> nordsc.com> wrote:
>>
>> On Feb 6, 2012, at 2:36 PM, Greg Young wrote:
>>
>>> Its pretty well known how to do a quick pub/sub with atom pub. If we
>>> get loads and loads of consumers though it might be beneficial to say
>>> hang a http connection
>>
>> Huh? Are you saying, you want to switch from polling to push when number of users grow?
>>
>> I'd suggest that, the more number of users you have, the less is push a good architectural choice. Better to make use of HTTP caching to decrease umber of requests that actually hit your backend.
>>
>> Look at archived feeds for this purpose <http://tools.ietf.org/html/rfc5005> or check out <http://roy.gbiv.com/untangled/2008/paper-tigers-and-hidden-dragons> which I think is indeed a very practical solution despite its 'esoteric' appeal at first glance :-)
>>
>> If you feel you must use push, then there are solutions already such as XMPP.
>>
>>
>> Jan
>>
>>
>>> and push results down the pipe in near real
>>> time as opposed to polling (performance optimization only). This can
>>> be done in a generic way, does anyone happen to know of a system that
>>> just does that out of the box as opposed to building it?
>>>
>>> --
>>> Le doute n'est pas une condition agréable, mais la certitude est absurde.
>>>
>>
>
>
>
> --
> Le doute n'est pas une condition agréable, mais la certitude est absurde.
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

__._,_.___
Recent Activity:
.

__,_._,___
Permalink | Reply | 0 comments |
headers
Thomas Koch | 6 Feb 19:43
Picon
Gravatar

Java Framework to provide Facades for Media Types / Resources

 

Hi,

for my bachelor thesis[1] (reusable components in multi MediaType rest
applications) I invented a way to hide the details of the Resource
Representation from the method handler (Resource method in JAX-RS) and wanted
to know whether something similar already exists.

I've posted the full details on StackOverflow:
http://stackoverflow.com/questions/9165185/java-framework-to-provide-facades-
for-media-types-resources

Best regards,

Thomas Koch, http://www.koch.ro

__._,_.___
Recent Activity:
.

__,_._,___
Permalink | Reply | 0 comments |
headers
Ruben Verborgh | 7 Feb 09:21
Picon
Favicon
Gravatar

Your take on Services versus the Semantic Web? [2nd CfP LAPIS 2012]

Dear REST enthousiast,

Do you think there’s a joint future for Services and the Semantic Web?
Or is your opinion that they’ll never work together?

Either answer is great, because we want you to join the discussion at the LAPIS workshop!
It’s roughly one month before the deadline, so consider submitting a paper (4 or 8 pages) or a discussion
starter (1 paragraph).

Comments? Questions?
Don’t mail me – just submit them directly to the workshop ;-)

Best,

Ruben
http://lapis2012.linkedservices.org/

* * * * * * * * * * * * * * * * * * * * * * *

    LAPIS 2012
    Linked APIs for the Semantic Web
    ESWC 2012 workshop
    May 27th, 2012
    http://lapis2012.linkedservices.org/

* * * * * * * * * * * * * * * * * * * * * * *

"The Web as I envisioned it, we have not seen it yet."
  – Tim Berners-Lee

"Services and the Semantic Web: it's complicated."
  – anonymous gossip

"Semantic Web and APIs: an essential problem in need of a fresh look."
  – LAPIS 2012 mission

=======================
 Challenge for Papers – What do *you* have to say about Linked APIs and the Semantic Web?
=======================

LAPIS 2012 in 5 questions
-------------------------

Why?       The Web has changed: services become resource-oriented APIs. We must react now.
Goal?      Exploring the opportunities resource-oriented APIs offer, especially in combination with links.
For whom?  Motivated researchers from the REST, Semantic Web, and Linked Data communities.
What?      A truly interactive workshop, driven by constructive discussion and dialog.
Format?    An inspiring day. Morning: talks and dialog. Afternoon: brainstorm and discussion

LAPIS 2012 in 5 bullets
-----------------------
The main goal of the LAPIS workshop is to give birth to new ideas and visions, through presentations that
encourage interaction and discussion. Topics of discussion include:

- defining Linked APIs, what they could look like, and what role links can play
- identifying the essential building blocks for enabling Linked APIs
- pinpointing challenges to move from resource-oriented APIs towards Linked APIs
- capturing added value of Linked APIs for the Semantic Web and REST communities
- designing applications by connecting Linked Data and Linked APIs for reading and writing
The above list is not exhaustive and we therefore actively encourage participants to be creative.

LAPIS 2012 wants your submission
--------------------------------
Regular paper (8 pages)
    Regular papers focus on new ideas or technologies you have developed that relate to Linked APIs.
    We are very open-minded towards the workshop scope, and expect the same from you.

    Be original. Be creative. But most of all: be at least a little controversial – generate discussion.
    We're not looking for the next Big Invention. Workshop participants want to discover and to learn.

    Details: http://lapis2012.linkedservices.org/call-for-papers/

Vision paper (4 pages)
    Vision papers focus on creative ideas and concepts, even if there are no concrete results yet.
    Having more questions than answers can in fact be a plus… if you find the right questions.

    Details: http://lapis2012.linkedservices.org/call-for-papers/

Wild ideas and discussion starters (1 paragraph)
    Besides the traditional papers component, we would also like to run an experiment.
    We want your wildest ideas and discussion topics to make LAPIS 2012 an interactive workshop.

    Details: http://lapis2012.linkedservices.org/call-for-papers/

Motivated for this challenge?
-----------------------------

Great! Visit us at http://lapis2012.linkedservices.org/
Your deadline is March 4th, 2012, and the workshop will take place on May 27th or 28th.

LAPIS 2012 is organized by Craig Knoblock, Barry Norton, Ruben Verborgh, Sebastian Speiser, and Maria Maleshkova.
LAPIS 2012 is driven by you, its participants. Come and discuss with us!

http://lapis2012.linkedservices.org/

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/rest-discuss/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/rest-discuss/join
    (Yahoo! ID required)

<*> To change settings via email:
    rest-discuss-digest <at> yahoogroups.com 
    rest-discuss-fullfeatured <at> yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    rest-discuss-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
Permalink | Reply | 0 comments |
headers
Kevin Duffey | 7 Feb 20:47
Picon
Favicon

How to make RPC-like call RESTfully

 

Hi all,

I am trying to do the best I can for our API needs to avoid making some REST calls basically be RPC calls. I can't explain in detail regarding the company I work for as we're still in stealth/startup mode so I'll do the best I can to make sense.

Our API uses HtmlUnit (Java) to "scrape" some web sites. Basically we pull down a sites login page, try some credentials that the consumer passed to us, and attempt to log a user in. It sounds fishy.. but we're really not trying to randomly log in to sites and steal credentials. The consumer of our API will ask their end users for credentials, pass those to us via a REST call and we'll attempt to validate the credentials are good, sending back a response to the consumer that they are good or not. However, as far as I can tell this does not modify a resource, or create a new resource on our server side. It's basically a proxy for a consumer app to use our API to try validating user credentials for different services. The consumer gets the benefit of being able to avoid having to do the page scraping and/or using other service APIs..they just use our one API and specify the service and pass the credentials.

The problem is.. we cant use GET since you can't pass a body. I thought of query params for the creds, but that seems hacky to me. So PUT seems the logical method to use, passing in credentials (possibly other values too) in the body. Only, as I said above, we're not storing these values, changing any data on our API server side.. we're merely checking to see if what was sent to our API works at the service selected (lets say yahoo, gmail, etc). So I guess you could say the boolean flag of whether or not the creds worked changes..but that's not really the resource.

So I am asking you experts.. how is something like this done via REST? I know.. from all the posts I've read the past few years, I fit that mold of those trying to turn an RPC into REST. Essentially if the community was "ok" with using RPC like syntax with the ease of REST calls, I would be ok with this. Because it seems a lot of the community balks at using REST in lieu of SOAP and other RPC mechanisms, I am left to figuring out if there is some way to do this with REST.

Feel free to slap me around a bit if I am completely missing some key points about using REST. I think I have a pretty good understanding of it, but no doubt there is room to learn.

Thank you.

an>



__._,_.___
Recent Activity:
.

__,_._,___
Permalink | Reply | 3 comments |
headers
mike amundsen | 7 Feb 21:15
Picon
Favicon
Gravatar

Re: How to make RPC-like call RESTfully

 

Kevin:


not sure if this helps, but regarding the " as far as I can tell this does not modify a resource, or create a new resource" line, i'll share this observation:

First, the POST/PUT actions are _not_ reserved for creating/modifying some concrete entity in your server's problem domain. You can use these idempotent(PUT) and non-idempotent(POST) actions to send data bodies to the server for processing of all kinds including comparing the data against data on the server, logging for later use, etc.

I often "model" actions such as "login", "ticket request", "queue up a job", etc. as a "write-record" pattern. IOW, if you attempt to log into the server, I might log the action (date, time, username, other context data) for later audit review. When I do this, it makes good sense to use a POST w/ body to send the data. These actions often result in a new "resource" which hold the results of the attempt ("here's your ticket", "you job has been added to the queue", etc.) and sometimes this resource will be updated/refreshed over the life of the job, etc.

I think that would fit your scenario just fine. you need not save all the data sent by the user (i.e. password, etc.)


mca
http://amundsen.com/blog/
http://twitter.com <at> mamund
http://mamund.com/foaf.rdf#me




On Tue, Feb 7, 2012 at 14:47, Kevin Duffey <andjarnic <at> yahoo.com> wrote:


Hi all,

I am trying to do the best I can for our API needs to avoid making some REST calls basically be RPC calls. I can't explain in detail regarding the company I work for as we're still in stealth/startup mode so I'll do the best I can to make sense.

Our API uses HtmlUnit (Java) to "scrape" some web sites. Basically we pull down a sites login page, try some credentials that the consumer passed to us, and attempt to log a user in. It sounds fishy.. but we're really not trying to randomly log in to sites and steal credentials. The consumer of our API will ask their end users for credentials, pass those to us via a REST call and we'll attempt to validate the credentials are good, sending back a response to the consumer that they are good or not. However, as far as I can tell this does not modify a resource, or create a new resource on our server side. It's basically a proxy for a consumer app to use our API to try validating user credentials for different services. The consumer gets the benefit of being able to avoid having to do the page scraping and/or using other service APIs..they just use our one API and specify the service and pass the credentials.

The problem is.. we cant use GET since you can't pass a body. I thought of query params for the creds, but that seems hacky to me. So PUT seems the logical method to use, passing in credentials (possibly other values too) in the body. Only, as I said above, we're not storing these values, changing any data on our API server side.. we're merely checking to see if what was sent to our API works at the service selected (lets say yahoo, gmail, etc). So I guess you could say the boolean flag of whether or not the creds worked changes..but that's not really the resource.

So I am asking you experts.. how is something like this done via REST? I know.. from all the posts I've read the past few years, I fit that mold of those trying to turn an RPC into REST. Essentially if the community was "ok" with using RPC like syntax with the ease of REST calls, I would be ok with this. Because it seems a lot of the community balks at using REST in lieu of SOAP and other RPC mechanisms, I am left to figuring out if there is some way to do this with REST.

Feel free to slap me around a bit if I am completely missing some key points about using REST. I think I have a pretty good understanding of it, but no doubt there is room to learn.

Thank you.







__._,_.___
Recent Activity:
.

__,_._,___
Permalink | Reply | 2 comments |

Gmane