{"action":"created","issue":{"url":"https://api.github.com/repos/mamund/hal-forms/issues/14","repository_url":"https://api.github.com/repos/mamund/hal-forms","labels_url":"https://api.github.com/repos/mamund/hal-forms/issues/14/labels{/name}","comments_url":"https://api.github.com/repos/mamund/hal-forms/issues/14/comments","events_url":"https://api.github.com/repos/mamund/hal-forms/issues/14/events","html_url":"https://github.com/mamund/hal-forms/issues/14","id":152827199,"number":14,"title":"Process flow for HAL-FORM to support dynamic forms","user":{"login":"gillarramendi","id":503110,"avatar_url":"https://avatars.githubusercontent.com/u/503110?v=3","gravatar_id":"","url":"https://api.github.com/users/gillarramendi","html_url":"https://github.com/gillarramendi","followers_url":"https://api.github.com/users/gillarramendi/followers","following_url":"https://api.github.com/users/gillarramendi/following{/other_user}","gists_url":"https://api.github.com/users/gillarramendi/gists{/gist_id}","starred_url":"https://api.github.com/users/gillarramendi/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/gillarramendi/subscriptions","organizations_url":"https://api.github.com/users/gillarramendi/orgs","repos_url":"https://api.github.com/users/gillarramendi/repos","events_url":"https://api.github.com/users/gillarramendi/events{/privacy}","received_events_url":"https://api.github.com/users/gillarramendi/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":35,"created_at":"2016-05-03T17:13:51Z","updated_at":"2016-05-14T18:56:50Z","closed_at":null,"body":"Basically we have tried to follow the proposed process flow approach in the spec and we didn’t found a solution to deal with, when the URL of the form definition is dynamic.\r\nIn other words, the current proposed approach uses the rel as a URL. It means that the clients must know the rel, (I guess that the rel must be static) and does not work properly when the form content is dynamic and changes constantly (this URLs can not be inside the client).\r\n\r\nFor instance in the following example we can see the URL to prepare the form for a specific order:\r\n\r\n```json\r\n{\r\n  \"_links\": {\r\n    \"self\": {\r\n      \"href\": \"http://api.example.org/orders/1\",\r\n    },\r\n    \"http://api.example.org/orders/1/prepare-edit\": {       ← url to obtain the hal-form\r\n      \"href\": \"http://api.example.org/orders/1/edit\",\r\n    },\r\n  }\r\n}\r\n```\r\n\r\n\r\nOne possible solution for this case, could be to use another approach where we have independent rels, one for form preparation and another one for the submit, for instance:\r\n\r\n```json\r\n\"_links\" : {\r\n    ...\r\n    \"prepareForm\" : {\r\n      \"href\" : \"http://api.example.org/orders/1/prepare-edit\"    ← Url to create dynamic form\r\n    },\r\n    \"submitForm\" : {\r\n      \"href\" : \"http://api.example.org/orders/1/edit\"\r\n    }\r\n  }\r\n```\r\n\r\nThis solutions works well but the client don’t see the relation between both rels in the HAL response. In addition within our requirements (related to security), and once we don’t have the action URL within HAL-FORM, we need to infer this relation in some way to validate the incoming submit using the form definition. \r\n\r\nThis relation between both rels can be useful as well when we want to define the FORM in HTML format. I mean once we define action URL within HAL (the default behaviour) we don’t need to define again when we define the form. It’s important to note that HAL founder Mike Kelly likes HTML based form definitions.\r\n\r\n\r\nSo we have been thinking in a more suitable approach where the client can understand the relation between both rels and any tool or library can infer the relation between both rels as well. Basically we think that `type` property inside the link (from HAL spec) can be useful for that. For instance using this approach the HAL response:\r\n\r\n```json\r\n\"_links\": {\r\n      \"edit\": [{\r\n          “type” : “application/prs.hal-forms+json”,\r\n          \"href\" : \"http://api.example.org/orders/1/prepare-edit\"    ← Url to create dynamic form\r\n      },{\r\n          \"href\" : \"http://api.example.org/orders/1/edit\"\r\n      }]\r\n}\r\n```\r\n\r\nThe resulting hal-forms response:\r\n\r\n```json\r\n{\r\n  \"_links\" : {\r\n     \"self\" : {\r\n      \"href\" : \"http://api.example.org/orders/1/prepare-edit\"\r\n    }\r\n },\r\n  \"_templates\" : {\r\n    \"default\" : {\r\n      \"title\" : \"Edit\",\r\n      \"method\" : \"put\",\r\n      \"properties\" : [\r\n        ….\r\n      ]\r\n    }\r\n  }\r\n}\r\n```\r\n\r\n\r\nIn that way we solve both requirements. We can deal with dynamic URLs for form definitions and we can express the relation between both rels improving the readability for humans and tools processing for client and server sides.\r\n\r\nWhat do you think about this approach? Do you think it could be included in the HAL-FORM spec suggested process flow as the standard way to deal with this kind of dynamic forms? \r\n"},"comment":{"url":"https://api.github.com/repos/mamund/hal-forms/issues/comments/219237146","html_url":"https://github.com/mamund/hal-forms/issues/14#issuecomment-219237146","issue_url":"https://api.github.com/repos/mamund/hal-forms/issues/14","id":219237146,"user":{"login":"mamund","id":38344,"avatar_url":"https://avatars.githubusercontent.com/u/38344?v=3","gravatar_id":"","url":"https://api.github.com/users/mamund","html_url":"https://github.com/mamund","followers_url":"https://api.github.com/users/mamund/followers","following_url":"https://api.github.com/users/mamund/following{/other_user}","gists_url":"https://api.github.com/users/mamund/gists{/gist_id}","starred_url":"https://api.github.com/users/mamund/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mamund/subscriptions","organizations_url":"https://api.github.com/users/mamund/orgs","repos_url":"https://api.github.com/users/mamund/repos","events_url":"https://api.github.com/users/mamund/events{/privacy}","received_events_url":"https://api.github.com/users/mamund/received_events","type":"User","site_admin":false},"created_at":"2016-05-14T18:56:50Z","updated_at":"2016-05-14T18:56:50Z","body":"@dschulten :\r\n\r\nyeah - i got that backwards. sorry.\r\n\r\nin the end, the URL constructed for the HAL-FORMS request will be the value of the `rel` property.  how this value is derived (static or templated) is an implementation detail. it is up to the services to provide a template that can be successfully constructed by clients when relying on the algorithms in RFC6570.  \r\n\r\ni'll review the text for processing regarding constructing URLs from templates, but I suspect that text won't change much.\r\n\r\ni think the challenge faced here is how to use the spec to create the implementation you want. the discussion here continues to revolve around passing state information to services when fashioning HAL-FORMS responses. AFAICT, there is more than enough computing power already in the spec to do that (e.g. through templated URLs). \r\n\r\nit looks like the solution runs counter to some other design elements you want (e.g. static rel values) and that is a trade off you'll need to resolve in your implementation. there is nothing that i know of that can be written into the extension spec to make that trade-off for you.\r\n"}}