I have a web application that has many web services and an AJAX web client as well as some mobile clients. I won't call them RESTful web services, but I'm trying to get them closer.

One problem I have is that I am trying to avoid having any application state on the server. I have that with the exception of having an authenticated session. Nothing is stored in the session except for the user's "Subject" which knows whether or not it is authenticated and who it is authenticated as.

But I want to get all the way to having no session, but that means I have to authenticate with every request. My mobile clients have no trouble doing this. (In fact, they do it already.) However, this seems to be rather tricky from a browser.

If the ENTIRE application was in one web page, then you could just store the credentials in memory. However, if you have to go from one web page to another, it starts to get hairy.

Does anyone on this list have any best practices for avoiding having any session in web applications (Human to Machine) requiring authentication?

• New Members 3

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

• New Members 6

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

• New Members 5

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.

• New Members 5

Jorn:

Erik's list is a good start:
- supply defaults
- provide a range (select)
- indicate whether to show to a human (hidden)
- indicate mutability (disabled inputs cannot be changed)

Also, HTML5 offers very long list of other attributes with which
servers can use to communicate to the client input qualities value[1]

Certainly the mere _appearance_ of an input is "useful" is it not?

As an application evolves over time, servers can add/remove inputs at
selected points in the user-agent's interactions w/ the server, too.
These decisions can be completely context dependent. For example,
selected users (admins) might see diff inputs than others (guests).
During certain times (i.e. the DB is temporarily offline and does
support writes) inputs could simply be removed from forms for a time.
Workflows could be altered to move inputs from one form to another;
indicating when selected data elements are valid.

All of the variances I've listed here work with a "fixed" set of
inputs (or app-level vocabulary); IOW, there is no need to introduce
brand new input "names" That means the set of variances I've defined
work w/ user-agents there there is not human directly driving the
interactions (i.e. M2M cases).

If you add a human at runtime (i.e. H2M cases), you now have the
possibility of introducing entirely new inputs (i.e expanding the
app-level vocabulary) and continuing to evolve the app.

In fact, as Jon Moore (I think it was him) has pointed out, as long as
you code an M2M user-agent to treat all "unknown" input elements as
"pass through" (i.e. continue to include them in URI templates
(HTML.FORM <at> method="get") and body templates (HTML.FORM <at> method="post")
AND provide defaults for these brand-new input elements, then even M2M
use cases support evolution over time that includes "unknown" inputs.

Are there other features you have in mind that have not been included here?

[1] http://www.w3.org/TR/html5/the-input-element.html

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

---------- Forwarded message ----------
From: Jorn Wildt <jw <at> fjeldgruppen.dk>
Date: Fri, Jan 27, 2012 at 05:21
Subject: Re: What does a form tell my program?
To: mike amundsen <mamund <at> yahoo.com>

> what is it about those other things (ops, encoding, URL) that
> remains "useful' at runtime?

At runtime I can read action="{url}" and method="{method}" from the
<form ...> tag. From that my program can decide what the server wants
it to do. No need for a hard coded "post here" URL in my client. So
these elements are "useful" at runtime because it makes it possible
for the server to influence the client's behavior.

But I cannot see how tags like <input name="{name}"/> can change be
client's behavior at runtime. The client must have hard coded
knowledge of "{name}" - it cannot discover what "{name}" is at
runtime. So, at compile time, the developer reads the form, and using
his eyes and brain, decides what input tag is used for something. Then
he hard codes "{name}" into his client.

So, can the client discover something useful from <input
name="{name}"/> at runtime?

Did that explain it?

While writing this I was reminded of default values in <input> tags.
So, one useful, discoverable, feature of a input definition, is the
default value for that input. And hidden inputs adds other extra
values that the client need not know about. More?

/Jørn

• New Members 8

Markus,

as you've already mentioned in another post in this thread:

"The subject of this thread is "formats with native hypermedia support
going beyond GET""

So my list (see below) was about this topic ;)

Cheers,

Bo

On 1/17/2012 5:23 PM, Markus Lanthaler wrote:
>> I would propose to correct the list as following:
>
> Which list was wrong in your opinion? Currently I have the following two:
>
> Native hypermedia support beyond GET:
> - HTML (GET/POST/PUT)
> - Atom+AtomPub (GET/POST/PUT/DELETE)
> - WSDL (GET/POST/PUT/DELETE)
> - WADL (GET/POST/PUT/HEAD/DELETE)
> - Collection+JSON (GET/POST/PUT/DELETE)
> - CCXML (GET/POST) - thanks to Erlend
> - Shoji (GET/POST/PUT/DELETE) - thanks to Robert
>
> Allow "semantic" annotation of links which can be used to support other
> methods
> - HTML
> - Atom+AtomPub
> - HAL
> - RDF/XML, Turtle, N3, ...
> - JSON-LD
> - WADL/WSDL??
>
>
>
> --
> Markus Lanthaler
> <at> markuslanthaler
>
>
>
>
>> -----Original Message-----
>> From: rest-discuss <at> yahoogroups.com [mailto:rest-
>> discuss <at> yahoogroups.com] On Behalf Of Bob Ferris
>> Sent: Tuesday, January 17, 2012 10:53 PM
>> Cc: 'REST-Discuss Discussion Group'
>> Subject: Re: [rest-discuss] Formats with native hypermedia support
>>
>> Hi Markus,
>>
>> I would propose to correct the list as following:
>>
>> - HTML
>> - Atom& AtumPub
>> - Collection+JSON
>> - HAL
>>
>> Cheers,
>>
>>
>> Bo

• New Members 7

There was a discussion here some weeks ago about the use of forms in REST services. Since then I have been wondering about how much such a form tells my program at *runtime*.

For this discussion I am focusing on HTML forms as we know them from the web. These includes:

- Action URL
- Encoding
- Operation
- Inputs

At runtime my program can parse the action URL, the encoding and the operation, and use these to dynamically create a HTTP request.

But what about the input definitions (the actual payload)? Are they useful at runtime?

At compile-time (or "read the documentation time") the inputs are useful for telling my program (the developer) which values to that corresponds to what. As the developer I can see that the name of the person must be sent as "PersonName=xxx". But after this I don't see how the client program can use the input definitions for anything at runtime.

Have I overlooked some nice features of using forms?

One could decide to publish the identifiers for the input elements that is used. For instance saying that the input marked with id="name-of-person" defines the name of the input for the person's name. Like this:

<input id="name-of-person" name="PersonName"/>

But I don't see how that really changes anything - its just one more indirection to follow.

Thanks, Jørn

• New Members 7

• New Members 1

The API I'm building seems to need several types of collections and I
think I've identified at least 3:

1) Collections of all the resource of a type (for example all the
users) where new resource can be created, destroyed and updated. This
seems to be the canonical RESTful collection where POST to the
collection URI creates the new resource and then PUT and DELETE to the
resource URI updates and destroys it.

2) Collections that represent relationships between resources (for
example the friends of a user). New relationships between resources
can be created with POST, but it's not clear how they should be
removed as the target resource should still exist, just no longer be
referenced.

3) Collections that represent queues of references (for example a TODO
list for a user). This is more complicated as the collection is
ordered and so elements in arbitrary positions need to be added or
removed and again the target resources should not be deleted.

If anyone could point me to nice patterns for implementing 2 and 3 I'd
be very grateful.

Cheers,

Jim

• New Members 2