Step by step resource editing

Hi,

I'm having trouble figuring out how to implement a scenario with a Hydra
API. I'll describe the problem in terms of an ecommerce site rather than my
situation (creating a visualisation) as it will be more familiar to most
people.

Imagine you are going through the checkout process for an order. You need
to enter payment details and an address. In pseudo HTTP the process would
look something like this:

1) Request: payment form
GET /checkout/1/payment-form

2) Response: send payment form as html
200 OK

...html for payment form...

3) Request: save payment
POST /checkout/1/payment-form

number:xxxx-xxxx
exp: 2017/01

4) Response: payment stored, redirect to address page
303 See other
Location: /checkout/1/address-form

5) Request: address form
GET /checkout/1/address-form

6) Response: address form html
200 OK

...html for address form...

7) Request: send address
POST /checkout/1/address-form

street: my house, my town
phone: 111 222333

When we go through the process we are seeing two html forms being presented
one after the other - the payment form then the address form. I can't find
a way to do this in Hydra though. The payment form can be opened with
something like the following:

"supportedOperation": [
  {
    "method": "POST",
    "label": "Make payment",
    "expects": "vocab:PaymentDetails",
    "returns": "vocab:AddressDetails"
  }
]

The problem is with the next phase - the server accepts the payment and
redirects to the address page - but how do you signal to the Hydra client
that you want the address form displayed? In other words how would you do
steps 5 and 6 in the same way you'd do it in html (displaying a form after
you've filled in another form).

After the payment is submitted to the server (step 3) the Hydra client
would follow the HTTP 303 redirect in the response and get the contents of
the empty address page (/checkout/1/address-form), but how would the client
know it needs to prompt the Hydra client for more information rather than
just display the empty address form (using the SupportedClass
'vocab:AddressDetails')?

One option might be to only have one supported operation on the
vocab:AddressDetails (a POST operation) that signals to the client the only
option is to do a form POST? This doesn't sound very attractive though -
it's expecting the client to behave in a 'magic' way to a certain set of
conditions. It feels like there should be a way to say 'display the
vocab:AddressDetails SupportedClass as a form' rather than the default
option of having it displayed as a static page.

In broader terms it's a case of building up a Resource through several
steps (an order checkout in this example). 'Wizards' work in a similar way.
Some of those steps can involve routing (following the ecommerce example -
does the user want gift wrapping options?), so it's not easy to load the
whole process into one form post (with one SupportedClass).

Any ideas on how to solve this would be much appreciated. I'm building a
Hydra Javascript client which mimics a Single Page Web Application, so it
would be good to make the process match user expectations (e.g. make the
Hydra API mimic the Amazon checkout process rather than changing the
checkout process to work around Hydra).

Thanks,

Kev
-- 
www.dataunity.org
twitter: @data_unity