| Time |
S |
Nick |
Message |
| 00:00 |
|
sfdebug |
how can i specify the HTTP verb on the response links...? |
| 00:00 |
|
_ollie |
Depends on how the hypermedia type works. HAL requires you to attach that to the link relation. Others return the HTTP verb with the response: { links : { foo : { href : …, method : … } } } |
| 00:03 |
|
mamund |
sfdebug Siren media type works pretty much like HTML. you can specify method, args, URL, even payload media type for each transition |
| 00:04 |
|
mamund |
Collection+JSON relies on CRUD assumptions (like Atom) but also allows you to specify args/params |
| 00:04 |
|
mamund |
as _ollie said, HAL expects all that to be associated with the link_rel value. |
| 00:04 |
|
_ollie |
mamund: have you ever stumbled above ION? http://ionwg.org/draft-ion.html |
| 00:05 |
|
mamund |
i created HAL-FORMS to turn that into a machine-readable thing, tho. |
| 00:05 |
|
mamund |
ION, hmm... |
| 00:05 |
|
mamund |
no |
| 00:05 |
|
mamund |
just looking at it now |
| 00:06 |
|
_ollie |
It's been created by Les Hazelwood from Stormpath. They're heavily chasing me down to implement support for it in Spring HATEOAS but I find it quite convoluted. |
| 00:06 |
|
mamund |
right - seems like there is very little structure here to hold onto |
| 00:07 |
|
mamund |
would be tough to create a generic parser/client for this, i think. |
| 00:07 |
|
_ollie |
Just the decision whether something in the payload is a form seem horribly complex: http://ionwg.org/draft-ion.html#form-structure |
| 00:08 |
|
mamund |
yeah - looking at that now |
| 00:08 |
|
mamund |
ick |
| 00:09 |
|
mamund |
well, i like the metadata offerings for forms (required, placeholder, pattern, etc.) -- bsasically taking it all from HTML. |
| 00:10 |
|
_ollie |
That's what he mentioned to be one objective: be more complete than anything else already out there in terms of forms. |
| 00:10 |
|
mamund |
input type seems a bit over the top. would not want to implement that<g> |
| 00:10 |
|
mamund |
to be this explicit w/ forms, but to also have almost no metadata for returned data seems lopsided. |
| 00:11 |
|
mamund |
well, i don't really know the whole story, so i should slow down. |
| 00:11 |
|
sfdebug |
does anyone know if facebook website use his own WS API to make the website? |
| 00:11 |
|
mamund |
sfdebug sorry, don't know anything on that. |
| 00:11 |
|
sfdebug |
i do this question because i have i doubt about "when" use REST and when not... |
| 00:11 |
|
sfdebug |
for example |
| 00:12 |
|
mamund |
REST or HTTP? |
| 00:12 |
|
sfdebug |
if i have a web site and an mobile app |
| 00:12 |
|
_ollie |
mamund: Looks like the assume symmetry between a form and the payloads received. |
| 00:12 |
|
sfdebug |
i develop a WS API to the mobile app consume... |
| 00:12 |
|
sfdebug |
can or, must the site consume the same API? |
| 00:13 |
|
mamund |
_ollie: as in you would assume the metadata for a form field applies to the same field in returned data or items[]? |
| 00:13 |
|
_ollie |
right |
| 00:13 |
|
mamund |
ick |
| 00:13 |
|
_ollie |
:) |
| 00:13 |
|
_ollie |
yeah, short sighted |
| 00:13 |
|
mamund |
so what happens when the form is not returned? where is the metadata now? |
| 00:14 |
|
mamund |
i whiped up a thing for Siren to standardize object metadata. just something to get ma past some implementation challenges. |
| 00:14 |
|
mamund |
made it a separate "side-call", like the way i did w/ HAL-FORMS |
| 00:15 |
|
mamund |
but it's messy and can be a bit flakey. really a bummer on mobile, too. (battery killer to keep asking for out-of-band info) |
| 00:16 |
|
_ollie |
To me it looks like ION is assumed to be used as media type for forms mostly |
| 00:17 |
|
mamund |
might make a decent single-use media type (forms). |
| 00:17 |
|
_ollie |
Although they a collection example as well. |
| 00:17 |
|
mamund |
wonder if it would make sense to use it instead of HAL-FORMS for HAL responses |
| 00:17 |
|
mamund |
would like to see the OPTIONS input a bit more flexible. |
| 00:18 |
|
mamund |
define the options as another URL to return the data, maybe support type-ahead search. |
| 00:18 |
|
mamund |
proly could extend it to add that |
| 00:19 |
|
_ollie |
Not sure. HAL FORMS looks a lot more HALish than ION, so even for only aesthetic reasons |
| 00:19 |
|
mamund |
for sure. |
| 00:19 |
|
mamund |
but i've used HTML forms from HAL, too. |
| 00:19 |
|
_ollie |
Yeah, I discussed the "suggestions" proposal for HAL FORMS with Ander recently. |
| 00:20 |
|
mamund |
right - i totally droppd the ball on your PRs there, didn't i? |
| 00:20 |
|
mamund |
really sorry. |
| 00:20 |
|
_ollie |
And I think he updated the PR after we simplified it a bit. |
| 00:20 |
|
mamund |
i should get off my a$$ and sort those out |
| 00:20 |
|
_ollie |
Oh well, nothign too urgent :) |
| 00:20 |
|
mamund |
as long as you're able to do what you need. |
| 00:20 |
|
_ollie |
but I guess I'll get my hands onto the implementation again this week. |
| 00:21 |
|
mamund |
love that Spring seems to be leading the pack on working through these things |
| 00:21 |
|
sfdebug |
what's HAL FORMs? |
| 00:21 |
|
_ollie |
Actually, trying to implement a prototype for the initial proposal brought up a few issues and options for simplification |
| 00:21 |
|
mamund |
really? |
| 00:21 |
|
mamund |
sounds interesting |
| 00:22 |
|
_ollie |
I think the 3 different ways to provide the options were slightly different initially and now we got it to a quite consistent scheme but teh different options distinguished by different field names. |
| 00:22 |
|
mamund |
hmmm.... |
| 00:22 |
|
_ollie |
I think the PR has the new proposed version already. |
| 00:23 |
|
mamund |
well, i gotta get my head into the game then |
| 00:23 |
|
_ollie |
sfdebug: an extension to HAL that provides forms support |
| 00:23 |
|
sfdebug |
i don't know what is HAL, when you are telling about HAL, i was thinking you are telling about "Hardware Abstract Layer"... |
| 00:23 |
|
_ollie |
re spring & hypermedia: we've got a big foot in the enterprise, so if we can get more people to actually try hypermedia that could have a big effect |
| 00:24 |
|
_ollie |
sfdebug: HAL http://stateless.co/hal_specification.html |
| 00:24 |
|
sfdebug |
let me see. |
| 00:24 |
|
mamund |
_ollie: yep - you are a very influential force right now. |
| 00:24 |
|
_ollie |
sfdebug: https://rwcbook.github.io/hal-forms/ |
| 00:24 |
|
mamund |
not only can you introduce more people to hypemedia-style, you can learn from all of those experiences faster than most |
| 00:25 |
|
_ollie |
Yeah, a two way street |
| 00:25 |
|
mamund |
figure out what works, what's lame, and how to improve things so that they actually solve real problems at a low cast w/ high safety. |
| 00:26 |
|
_ollie |
I am half-way through the pull request for Spring HATEOAS that basically rewrites the link builders we currently have and replaces them with an affordance builder. we have prototypes to the produce HAL FORMS, Siren, Uber and XHTML from that metamodel. |
| 00:27 |
|
mamund |
that'd be great. i think a big thing we need for the _internal code_ space is to implement the representor-style patterns |
| 00:27 |
|
mamund |
affordance-builders is a great idea |
| 00:27 |
|
_ollie |
I guess we're gonna start with HAL FORMS only and leave the other ones as experimental for now |
| 00:27 |
|
_ollie |
I'd like to start simple and see what people do with it. |
| 00:27 |
|
mamund |
it should be a "no-brainer" for a dev to get a representation back from the object model... |
| 00:28 |
|
mamund |
representation = objectModel.toUBER() |
| 00:28 |
|
_ollie |
Emphasis on "should" :) |
| 00:28 |
|
mamund |
right - we worked through this w/ activeserializer, etc. |
| 00:28 |
|
mamund |
so this is clearly something that makes sense to people |
| 00:29 |
|
_ollie |
allowing user defined serialization customizations make this not as trivial as I thought initially |
| 00:29 |
|
mamund |
and devs are used to doing all sorts of goofy things to their object models to make it easier to support serializers |
| 00:29 |
|
mamund |
right - getting past generic JSON and XML is not simple. |
| 00:29 |
|
mamund |
or everyone would have already done it. |
| 00:29 |
|
_ollie |
Yeah, where it should be the other way round actually. |
| 00:30 |
|
mamund |
oh, objectModel = response.toObjectModel() |
| 00:30 |
|
mamund |
HTML folks sorted that out by creating the DOM |
| 00:30 |
|
mamund |
what many devs would like is a DOM.toMyModel() |
| 00:31 |
|
mamund |
harder. |
| 00:31 |
|
mamund |
getting the first one done -- myModel.toSiren() -- should be a focus first, i think. |
| 00:31 |
|
_ollie |
Yeah. |
| 00:32 |
|
mamund |
because, i suspect what's going to happen is -- after several successful attempts -- we'll find a pattern to leverage |
| 00:32 |
|
mamund |
think of the way markdown systems work... |
| 00:32 |
|
_ollie |
We basically hand the model to components to create the serialization and which one's chosen then depends on the configured supported types and content negotiation. |
| 00:32 |
|
|
bluezone joined #rest |
| 00:33 |
|
mamund |
there is a "engine" in between formats. that's the kind of thing we'll need eventually. |
| 00:33 |
|
_ollie |
The thing that seems most tricky is to get model right: include enough APi to express the needs of individual hypermedia formats. tricky one: input types. |
| 00:33 |
|
mamund |
for now, object-to-representation is going to be helpful by lowering the cost of supporting a new format and reducing the need to create long drawn-out arguments about "which single format we should support" |
| 00:34 |
|
_ollie |
ACK |
| 00:34 |
|
mamund |
yeah - fidelity across formats willb e an issue -- it already is today. |
| 00:34 |
|
_ollie |
Input types are all very simple but usually slightly different in the different formats. |
| 00:34 |
|
mamund |
right - there are things you simply don't control in Cj that you have in Siren. |
| 00:35 |
|
sfdebug |
_ollie, here: http://stateless.co/hal_specification.html is all about HAL? |
| 00:35 |
|
mamund |
i've been doing two things there: 1) adding extensions in Cj responses, 2) leaving them out of Cj. |
| 00:35 |
|
_ollie |
I guess we'll just be going wuth a common set and a way to define media type specific extensions that will only be used if that particular one is rendered. |
| 00:35 |
|
mamund |
in both cases, clients don't complain. |
| 00:35 |
|
mamund |
yep - common types will emerge as we work through these things. |
| 00:35 |
|
_ollie |
sfdebug: that's what its <h1> suggests ;) |
| 00:35 |
|
mamund |
we won't build "the perfect media type" until we make _lots_ of media types! |
| 00:36 |
|
_ollie |
mamund: which time zone are you in actually? |
| 00:36 |
|
mamund |
and weed out bad ones along the way. |
| 00:36 |
|
mamund |
US east coast |
| 00:36 |
|
mamund |
you? |
| 00:36 |
|
_ollie |
I see :). |
| 00:36 |
|
_ollie |
CET. Still fighting jet lag from a week in Las Vegas for SpringOne. |
| 00:37 |
|
mamund |
ahhhh |
| 00:37 |
|
mamund |
i should stop talking to you! |
| 00:37 |
|
_ollie |
:D |
| 00:38 |
|
_ollie |
But I'll probably call it a day for now. More time for you looking at the PR! :D |
| 00:38 |
|
mamund |
right! |
| 00:38 |
|
mamund |
thanks for the convo. talsk to you again soo. |
| 00:38 |
|
_ollie |
talk to you soon! |
| 01:07 |
|
|
fuzzyhorns joined #rest |
| 01:20 |
|
|
tonyacunar joined #rest |
| 03:14 |
|
|
tbsf joined #rest |
| 03:45 |
|
|
k_j joined #rest |
| 04:30 |
|
|
wsieroci joined #rest |
| 05:19 |
|
|
wsieroci_ joined #rest |
| 05:29 |
|
|
Sna4x81 left #rest |
| 06:10 |
|
|
_ollie joined #rest |
| 06:48 |
|
|
wsiqueir joined #rest |
| 06:56 |
|
|
shodan` joined #rest |
| 07:05 |
|
|
graste joined #rest |
| 07:12 |
|
|
DevAntoine joined #rest |
| 07:40 |
|
|
interop_madness joined #rest |
| 10:16 |
|
|
timg__ joined #rest |
| 12:05 |
|
|
tonyacunar joined #rest |
| 12:08 |
|
|
tonyacunar joined #rest |
| 13:01 |
|
|
graste joined #rest |
| 14:31 |
|
|
_ollie joined #rest |
| 14:49 |
|
|
_ollie joined #rest |
| 15:20 |
|
|
graste joined #rest |
| 15:41 |
|
|
tbsf joined #rest |
| 15:41 |
|
|
tbsf joined #rest |
| 16:01 |
|
|
tbsf joined #rest |
| 16:02 |
|
|
tbsf joined #rest |
| 17:11 |
|
|
wsieroci joined #rest |
| 17:16 |
|
|
k_j joined #rest |
| 17:30 |
|
|
k_j joined #rest |
| 18:40 |
|
|
anth0ny joined #rest |
| 18:49 |
|
|
tbsf joined #rest |
| 18:50 |
|
|
itscaleb_ joined #rest |
| 18:51 |
|
|
bigbluehat joined #rest |
| 18:59 |
|
|
ShekharReddy joined #rest |
| 19:09 |
|
|
sulky joined #rest |
| 19:12 |
|
|
Tomatosoup- joined #rest |
| 19:47 |
|
|
bigbluehat joined #rest |
| 19:47 |
|
|
ShekharReddy joined #rest |
| 20:27 |
|
|
Coldblackice joined #rest |
| 21:32 |
|
|
tbsf joined #rest |
| 22:03 |
|
|
tbsf joined #rest |
| 22:03 |
|
|
tbsf joined #rest |
| 22:41 |
|
|
fuzzyhorns joined #rest |
| 23:26 |
|
|
tonyacunar joined #rest |
| 23:48 |
|
|
fuzzyhorns joined #rest |
