Forms for machine-to-machine interaction
Jørn Wildt
usability of forms for machine-to-machine interaction. Hopefully someone can
add a missing piece for me?
This time I will be a bit more specific: my work with REST APIs has
primarily been for integration services of the kind "when X happens in
system A then ensure X is somehow propagate to system B" - where for
instance X can be the creation of a new user that also needs to exist in
system B.
In these scenarios there tends to be a rather tight coupling between the
various sub-systems and the integration service must know in advance what
kind of data to transfer and its exact type information to work with the
(REST) API of system B to propagate event X from system A.
Now lets assume a REST service in system B exposes an HTML form (or another
media type specific kind of form) that describes HOW to interact with system
B. But for the integration service to work, it must know WHAT kind of data
to send to B, more specifically it must be hardwired to know the vocabulary
of a Person type in system B - what names to use for the properties of the
shared type Person.
So my integration client will be hardwired with knowledge about names and in
an HTML form this means the names of the <input> elements. This is not
something that can be discovered at runtime. So what is left for the client
to discover is HOW to move the data: the action URL, the operation
(POST/PUT/other), the prefered text encoding and the media type
(form-urlencoded or multipart data) - the <input> elements can be ignored.
I can see how this fits with the REST mantra: REST is about HOW to
interact - not WHAT we are interacting with. But does this setup gain much
by using forms in this way? The HOW in this case won't change often - but
the WHAT data type probably will.
The net result seems to be that we add some complexity with the form
parameters - but don't gain much, if anything, from it. Not that it is
difficult to read a form definition - but its extra work that doesn't seem
to add anything realy useful.
The alternative is to use link relations with heavy semantics. Like a link
relation where the (out of band) documentation states "POST properties
p1,p2,p3,... to the link URL, using form-urlencoded".
Can someone help me to either see what I will gain by using forms in this
scenario, or give some other examples where forms are more useful (implying
that, yes, forms are not that useful for this purpose)?
Is my problem that I am too narrow minded? The REST API/service may not ONLY
only be for integration in the future - perhaps I am missing some future
benefits that I don't see know if we open it up for more uses?
Thanks, J�rn
mca
I've been doing some experiments on this. While it's quite early, I
have been able to build functional "bots" that handle forms as they
appear by setting up the following restrictions:
- use PUT and DELETE (always idempotent writes)
- agree ahead of time on a dictionary of names/values (i.e. binding on
a vocabulary)
- include only one form per representation (no need to "pick a form" use use)
- wire the server to provide default values where acceptable
- wire the server to accept partial forms posting (reduce "required"
fields to zero)
- wire the server to (eventually) treat repeated requests for the same
URI as a DoS attack (to halt clients that are "stuck")
with only (ha, "only") these restrictions I've been able to build
clients that successfully handle forms as they appear within the
representation. these clients are able to "reach a goal" (complete a
task) very consistently.
it's early, but trivial samples are here:
https://github.com/mamund/miss-grants-controlller
https://github.com/mamund/m2m-no-fail-form
mush work needs to be done to see how this scales and what it takes to
write non-trivial solutions using this pattern. i've not seen much
else in this area (currently doing the searches now).
any and all feedback is welcome both here and in the repo.
thanks.
mca
http://amundsen.com/blog/
http://twitter.com@mamund
http://mamund.com/foaf.rdf#me
> Thanks, Jørn
>
> --
> You received this message because you are subscribed to the Google Groups
> "Hypermedia Web" group.
> To post to this group, send email to hyperme...@googlegroups.com.
> To unsubscribe from this group, send email to
> hypermedia-we...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/hypermedia-web?hl=en.
>
Mike Kelly
>
> - agree ahead of time on a dictionary of names/values (i.e. binding on
> a vocabulary)
>
How significant do you think this specific limitation is? Is it always
necessary in forms for m2m?
Cheers,
Mike
William Martinez
FORMS by themselves are not the whole solution. As Mike Amundsen says,
you will need other things.
1. Forms will give you exactly what you mention below: action URL,
operation, what fields/parameters are needed, a hint on their type.
IOW, Forms offers the structure of the message and a simple interaction
definition. The interaction is a "control" artifact, and the data
structure is a business artifact.
2. So, all you need is a way to find out how to fill in all the fields.
Well, that is achieved, as Mike also says, using a dictionary or
glossary. This is happening at business level. Your concern will then be
if that is shared knowledge or a simple hardwiring of field names,
making the actual benefit of using forms a zero value.
For you particular scenario, that is totally true. Forms are in a
sense a way to tell the user/client what to fill in and where to deliver
it. If the information coming from system A varies, and also the
information system B needs also varies, a Form plus a Glossary can help
you keep both free to be changing over time.
Just in case, let me tell you a glossary or vocabulary is more than just
a dictionary. It is a component capable of handling different business
concepts (names, synonyms) and map them to data sources. So, you can
read the name of an input tag into the glossary and it will fetch the
data from the sources (even if the field in the remote database has a
very different name), or it can tell what other names that input field
has in business terms. The glossary is not written in hard stone in
code, is it a generic tool that you feed up with data. If you have a
learning component, that vocabulary can grow by itself.
But, As I'm telling you, all this makes sense if you have a highly
variable system, but if your systems have a very finite set of data that
is pretty much static, you are right.
Cheers
William.
Jørn Wildt
/Jørn
> To post to this group, send email to hypermedia-web@googlegroups.com.
> To unsubscribe from this group, send email to
mca
First, as this is early in my experiments, i can't make any claims on
advantages _yet_<g>.
My attempts here on discovering "what it would take" to build
long-lived automata that use hypermedia as the engine of application
state. To that end, the "rules" I laid out are the ones that are
working for me right now.
I've only been at this a couple months, but i've come upon a couple
unexpected discoveries. Basically, writing the client is NOT the hard
part. The server has some added work, tho. the Media type design is
very easy, but mapping the problem domain to representations has
proven to be the most challenging aspect so far.
I promise to write some blog posts and update the list once I get back
from my trip and have time to sort things out in a read-able form.
mca
http://amundsen.com/blog/
http://twitter.com@mamund
http://mamund.com/foaf.rdf#me
>> > To post to this group, send email to hyperme...@googlegroups.com.
>> > To unsubscribe from this group, send email to
>> > hypermedia-we...@googlegroups.com.
>> > For more options, visit this group at
>> > http://groups.google.com/group/hypermedia-web?hl=en.
>> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "Hypermedia Web" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/hypermedia-web/-/0pNnt81u5GMJ.
>
> To post to this group, send email to hyperme...@googlegroups.com.
> To unsubscribe from this group, send email to
> hypermedia-we...@googlegroups.com.
Jørn Wildt
loved to buy you a beer :-)
/J�rn
----- Original Message -----
From: "mca" <m...@amundsen.com>
To: <hyperme...@googlegroups.com>
Sent: Tuesday, April 10, 2012 6:53 PM
Subject: Re: Forms for machine-to-machine interaction
J�rn:
First, as this is early in my experiments, i can't make any claims on
advantages _yet_<g>.
My attempts here on discovering "what it would take" to build
long-lived automata that use hypermedia as the engine of application
state. To that end, the "rules" I laid out are the ones that are
working for me right now.
I've only been at this a couple months, but i've come upon a couple
unexpected discoveries. Basically, writing the client is NOT the hard
part. The server has some added work, tho. the Media type design is
very easy, but mapping the problem domain to representations has
proven to be the most challenging aspect so far.
I promise to write some blog posts and update the list once I get back
from my trip and have time to sort things out in a read-able form.
mca
http://amundsen.com/blog/
http://twitter.com@mamund
http://mamund.com/foaf.rdf#me
On Tue, Apr 10, 2012 at 01:25, J�rn Wildt <j...@fjeldgruppen.dk> wrote:
> Mike, what are the benefits of this (seemingly complex?) approach compared
> to using a simple link-rel documented as "POST properties p1,p2,p3,... to
> the link URL, using form-urlencoded"?
>
> /J�rn
>
> Den mandag den 9. april 2012 23.16.55 UTC+2 skrev mamund:
>>
>> J�rn:
>> > Thanks, J�rn
mca
Oh, we MUST meet at some point!
Mike Amundsen
Too bad you are not in Copenhagen now that you visit Europe - would have loved to buy you a beer :-)
/Jørn
----- Original Message ----- From: "mca" <m...@amundsen.com>
Sent: Tuesday, April 10, 2012 6:53 PM
Subject: Re: Forms for machine-to-machine interaction
Jørn:
First, as this is early in my experiments, i can't make any claims on
advantages _yet_<g>.
My attempts here on discovering "what it would take" to build
long-lived automata that use hypermedia as the engine of application
state. To that end, the "rules" I laid out are the ones that are
working for me right now.
I've only been at this a couple months, but i've come upon a couple
unexpected discoveries. Basically, writing the client is NOT the hard
part. The server has some added work, tho. the Media type design is
very easy, but mapping the problem domain to representations has
proven to be the most challenging aspect so far.
I promise to write some blog posts and update the list once I get back
from my trip and have time to sort things out in a read-able form.
mca
http://amundsen.com/blog/
http://twitter.com@mamund
http://mamund.com/foaf.rdf#me
On Tue, Apr 10, 2012 at 01:25, Jørn Wildt <j...@fjeldgruppen.dk> wrote:
Mike, what are the benefits of this (seemingly complex?) approach compared
to using a simple link-rel documented as "POST properties p1,p2,p3,... to
the link URL, using form-urlencoded"?
/Jørn
Den mandag den 9. april 2012 23.16.55 UTC+2 skrev mamund:
Jørn:
> Thanks, Jørn
>
> --
> You received this message because you are subscribed to the Google
> Groups
> "Hypermedia Web" group.
> To post to this group, send email to hypermedia-web@googlegroups.com.
> To unsubscribe from this group, send email to
> For more options, visit this group at
> http://groups.google.com/group/hypermedia-web?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"Hypermedia Web" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/hypermedia-web/-/0pNnt81u5GMJ.
To post to this group, send email to hypermedia-web@googlegroups.com.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/hypermedia-web?hl=en.
--
You received this message because you are subscribed to the Google Groups "Hypermedia Web" group.
To post to this group, send email to hypermedia-web@googlegroups.com.
To unsubscribe from this group, send email to hypermedia-web+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/hypermedia-web?hl=en.
--
You received this message because you are subscribed to the Google Groups "Hypermedia Web" group.
To post to this group, send email to hypermedia-web@googlegroups.com.
To unsubscribe from this group, send email to hypermedia-web+unsubscribe@googlegroups.com.
Glenn Block
Sent from my Windows Phone
From: mca
Sent: 4/10/2012 12:15 PM
To: hyperme...@googlegroups.com
To unsubscribe from this group, send email to hypermedia-we...@googlegroups.com.