I recently delivered a talk on building hypermedia systems with ASP.NET Web
API. It is online here: http://vimeo.com/53261707. The talk is in two main
parts with the first focusing on the what and why of Hypermedia and the
second on approaches.
On Monday, November 12, 2012 4:10:06 AM UTC-5, Glenn Block wrote:
> Hi folks
> I recently delivered a talk on building hypermedia systems with ASP.NETWeb API. It is online here: > http://vimeo.com/53261707. The talk is in two main parts with the first > focusing on the what and why of Hypermedia and the second on approaches.
The one thing that didn't work in the talk was showing consumption of the
XHTML API from a non-browser client. For some reason I got a weird error so
I skipped over it. However if you look in the RestBugs project, there is a
console client which "should" work.
As for the hypermedia discussion, that was more of a chronicle than a
discussion, but good stuff there.
I am still of the mind that I see the usefullness of XHTML but it's not the
One-True-MediaType-That-Rules-Them-All for me :-)
On Mon, Nov 12, 2012 at 11:39 AM, landlessness <br...@apigee.com> wrote:
> great stuff, Glenn.
> very helpful for a hypermedia luddite like me to see lotsa code.
> also, somehow I had missed the HTML as API media type discussion back in
> July. thanks for calling that out.
> -b
> On Monday, November 12, 2012 4:10:06 AM UTC-5, Glenn Block wrote:
>> Hi folks
>> I recently delivered a talk on building hypermedia systems with ASP.NETWeb API. It is online here:
>> http://vimeo.com/**53261707 <http://vimeo.com/53261707>. The talk is in
>> two main parts with the first focusing on the what and why of Hypermedia
>> and the second on approaches.
>> Feedback welcome.
>> Glenn
> --
> You received this message because you are subscribed to the Google Groups
> "API Craft" group.
> To unsubscribe from this group, send email to
> api-craft+unsubscribe@googlegroups.com.
> Visit this group at http://groups.google.com/group/api-craft?hl=en.
Glenn, I see you have a Node version of RestBugs (https://github.com/glennblock/RestBugs), which is cool. Do you know if the .NET version will run on Mono for the non-Windows OS folks?
For list posterity: To add some context around the "HTML for Hypermedia APIs" discussion, Jon Moore has a good post here: http://codeartisan.blogspot.com/2012/07/using-html-as-media-type-for-.... It links back to some relevant API Craft conversations. There was also a lot of Twitter chatter going around at that time. I'll spare you that conversation. :)
On Nov 12, 2012, at 3:10 PM, Glenn Block <glenn.bl...@gmail.com> wrote:
> The one thing that didn't work in the talk was showing consumption of the XHTML API from a non-browser client. For some reason I got a weird error so I skipped over it. However if you look in the RestBugs project, there is a console client which "should" work.
> As for the hypermedia discussion, that was more of a chronicle than a discussion, but good stuff there.
> I am still of the mind that I see the usefullness of XHTML but it's not the One-True-MediaType-That-Rules-Them-All for me :-)
> On Mon, Nov 12, 2012 at 11:39 AM, landlessness <br...@apigee.com> wrote:
> great stuff, Glenn.
> very helpful for a hypermedia luddite like me to see lotsa code.
> also, somehow I had missed the HTML as API media type discussion back in July. thanks for calling that out.
> -b
> On Monday, November 12, 2012 4:10:06 AM UTC-5, Glenn Block wrote:
> Hi folks
> I recently delivered a talk on building hypermedia systems with ASP.NET Web API. It is online here: http://vimeo.com/53261707. The talk is in two main parts with the first focusing on the what and why of Hypermedia and the second on approaches.
> Feedback welcome.
> Glenn
> -- > You received this message because you are subscribed to the Google Groups "API Craft" group.
> To unsubscribe from this group, send email to api-craft+unsubscribe@googlegroups.com.
> Visit this group at http://groups.google.com/group/api-craft?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "API Craft" group.
> To unsubscribe from this group, send email to api-craft+unsubscribe@googlegroups.com.
> Visit this group at http://groups.google.com/group/api-craft?hl=en.
On Mon, Nov 12, 2012 at 12:22 PM, Kevin Swiber <kswi...@gmail.com> wrote:
> Watching now!
> Glenn, I see you have a Node version of RestBugs (
> https://github.com/glennblock/RestBugs), which is cool. Do you know if
> the .NET version will run on Mono for the non-Windows OS folks?
> For list posterity: To add some context around the "HTML for Hypermedia
> APIs" discussion, Jon Moore has a good post here:
> http://codeartisan.blogspot.com/2012/07/using-html-as-media-type-for-....
> It links back to some relevant API Craft conversations. There was also a
> lot of Twitter chatter going around at that time. I'll spare you that
> conversation. :)
> On Nov 12, 2012, at 3:10 PM, Glenn Block <glenn.bl...@gmail.com> wrote:
> Sure thing Brian.
> The one thing that didn't work in the talk was showing consumption of the
> XHTML API from a non-browser client. For some reason I got a weird error so
> I skipped over it. However if you look in the RestBugs project, there is a
> console client which "should" work.
> As for the hypermedia discussion, that was more of a chronicle than a
> discussion, but good stuff there.
> I am still of the mind that I see the usefullness of XHTML but it's not
> the One-True-MediaType-That-Rules-Them-All for me :-)
> On Mon, Nov 12, 2012 at 11:39 AM, landlessness <br...@apigee.com> wrote:
>> great stuff, Glenn.
>> very helpful for a hypermedia luddite like me to see lotsa code.
>> also, somehow I had missed the HTML as API media type discussion back in
>> July. thanks for calling that out.
>> -b
>> On Monday, November 12, 2012 4:10:06 AM UTC-5, Glenn Block wrote:
>>> Hi folks
>>> I recently delivered a talk on building hypermedia systems with ASP.NET<http://asp.net/>Web API. It is online here:
>>> http://vimeo.com/**53261707 <http://vimeo.com/53261707>. The talk is in
>>> two main parts with the first focusing on the what and why of Hypermedia
>>> and the second on approaches.
>>> Feedback welcome.
>>> Glenn
>> --
>> You received this message because you are subscribed to the Google Groups
>> "API Craft" group.
>> To unsubscribe from this group, send email to
>> api-craft+unsubscribe@googlegroups.com.
>> Visit this group at http://groups.google.com/group/api-craft?hl=en.
> --
> You received this message because you are subscribed to the Google Groups
> "API Craft" group.
> To unsubscribe from this group, send email to
> api-craft+unsubscribe@googlegroups.com.
> Visit this group at http://groups.google.com/group/api-craft?hl=en.
> --
> You received this message because you are subscribed to the Google Groups
> "API Craft" group.
> To unsubscribe from this group, send email to
> api-craft+unsubscribe@googlegroups.com.
> Visit this group at http://groups.google.com/group/api-craft?hl=en.
Great talk, its nice to have a higher level representation of this stuff, with all the specs, dissertations etc. it sometimes gets a bit heave, this video has given me some inspiration of the node based Hypermedia API we are building at the start-up i am involved in.
Also nice to see some great stuff coming out of Microsoft, Web API looks great.
Collection+Json is the main Media type in the talk, and i have read about that in Mikes book , and even began to implement it(we created the formatter to deal with the general output) but it started to get a little verbose for us, especially when working with javascript and you losing the .notation to interact with the data for each object and having everything output as essentially a name value pair...
On Monday, November 12, 2012 10:10:06 AM UTC+1, Glenn Block wrote:
> Hi folks
> I recently delivered a talk on building hypermedia systems with ASP.NETWeb API. It is online here: > http://vimeo.com/53261707. The talk is in two main parts with the first > focusing on the what and why of Hypermedia and the second on approaches.
the biggest challenge (some would say drawback) to using my Collection+JSON
media type is that it was specifically designed to "break the back" of
object-style serializers in code libraries<g>.
I find that facing the notion of switching communications between machines
from object-oriented to state-oriented can be enlightening, even if it
turns out that's not what you decide to do for your project.
I think HAL does a very good job of providing hypermedia affordances while
still supporting object-style message passing. Be sure to check that one
out, too. It's also possible Siren would be a good fit, but I've not built
much w/ that one yet.
On Wed, Nov 21, 2012 at 3:43 PM, Roberto Modica <r...@modika.co.uk> wrote:
> Hi Glenn,
> Great talk, its nice to have a higher level representation of this stuff,
> with all the specs, dissertations etc. it sometimes gets a bit heave, this
> video has given me some inspiration of the node based Hypermedia API we are
> building at the start-up i am involved in.
> Also nice to see some great stuff coming out of Microsoft, Web API looks
> great.
> Collection+Json is the main Media type in the talk, and i have read about
> that in Mikes book , and even began to implement it(we created the
> formatter to deal with the general output) but it started to get a little
> verbose for us, especially when working with javascript and you losing the
> .notation to interact with the data for each object and having everything
> output as essentially a name value pair...
> Rob
> On Monday, November 12, 2012 10:10:06 AM UTC+1, Glenn Block wrote:
>> Hi folks
>> I recently delivered a talk on building hypermedia systems with ASP.NETWeb API. It is online here:
>> http://vimeo.com/**53261707 <http://vimeo.com/53261707>. The talk is in
>> two main parts with the first focusing on the what and why of Hypermedia
>> and the second on approaches.
>> Feedback welcome.
>> Glenn
> --
> You received this message because you are subscribed to the Google Groups
> "API Craft" group.
> To unsubscribe from this group, send email to
> api-craft+unsubscribe@googlegroups.com.
> Visit this group at http://groups.google.com/group/api-craft?hl=en.
It wasn't a criticism, hope it didn't come across like that, from reading your book (which really is great by the way) with json not having the HFactors built in and going for a general style like you have it is not going to fit every problem but will work for many, we get that, its clearly outlined in the chapter where you introduce it.
We have implemented the formatter, so the promise was there and we took it, and we have a very basic implementation outputting collection+json and the data fits, and will continue to fit moving forwards, if we add things the API will evolve and version-ing in this instance shouldn't be an issue as everything is discoverable, and for that you have done a really great job. Its just when we started implementing a simple client, we just seemed to lose the object style we are used too. Some of this is down to understanding as well, because we are trying to shift the mindset from human API's to an API for everything, machine and all, and that is sometimes the difficult notion to wrap your head around, even if the concept is simple when you read it out loud.
We are new to this, and the number of "REST"ish apis that are around have probably clouded the judgement because they are all focused on the object being the resource (model to resource direct mapping) as they pan out their REST philosophy, when i guess the switch has to be from a point of view of the resources being agnostic and discoverable, which with collection+json they are and a truer representation or REST.
We are looking at Hal at the moment, comparing the two and see which will fit our problem that little bit better (we may stick with collection+json or use both :))
Great to have all the leaders in this field actively come and comment, really is a great boost for people to further their knowledge.
On Wednesday, November 21, 2012 9:00:50 PM UTC, Mike Amundsen wrote:
> Jumping in here...
> the biggest challenge (some would say drawback) to using my > Collection+JSON media type is that it was specifically designed to "break > the back" of object-style serializers in code libraries<g>.
> I find that facing the notion of switching communications between machines > from object-oriented to state-oriented can be enlightening, even if it > turns out that's not what you decide to do for your project.
> I think HAL does a very good job of providing hypermedia affordances while > still supporting object-style message passing. Be sure to check that one > out, too. It's also possible Siren would be a good fit, but I've not built > much w/ that one yet.
> On Wed, Nov 21, 2012 at 3:43 PM, Roberto Modica <r...@modika.co.uk<javascript:> > > wrote:
>> Hi Glenn,
>> Great talk, its nice to have a higher level representation of this stuff, >> with all the specs, dissertations etc. it sometimes gets a bit heave, this >> video has given me some inspiration of the node based Hypermedia API we are >> building at the start-up i am involved in.
>> Also nice to see some great stuff coming out of Microsoft, Web API looks >> great.
>> Collection+Json is the main Media type in the talk, and i have read about >> that in Mikes book , and even began to implement it(we created the >> formatter to deal with the general output) but it started to get a little >> verbose for us, especially when working with javascript and you losing the >> .notation to interact with the data for each object and having everything >> output as essentially a name value pair...
>> Rob
>> On Monday, November 12, 2012 10:10:06 AM UTC+1, Glenn Block wrote:
>>> Hi folks
>>> I recently delivered a talk on building hypermedia systems with ASP.NETWeb API. It is online here: >>> http://vimeo.com/**53261707 <http://vimeo.com/53261707>. The talk is in >>> two main parts with the first focusing on the what and why of Hypermedia >>> and the second on approaches.
>>> Feedback welcome.
>>> Glenn
>> -- >> You received this message because you are subscribed to the Google Groups >> "API Craft" group. >> To unsubscribe from this group, send email to >> api-craft+...@googlegroups.com <javascript:>. >> Visit this group at http://groups.google.com/group/api-craft?hl=en.
totally understand where you are coming from here. no need to apologize,
etc. your observations are spot on and this is a great forum for discussing
the pros/cons of any design when implementing a real-life solution.
keep up the good work and continue to post here as there are lots of folks
who are interested in the details (good and bad) arising from a real-life
implementation.
On Thu, Nov 22, 2012 at 4:28 AM, Roberto Modica <r...@modika.co.uk> wrote:
> Hi Mike,
> It wasn't a criticism, hope it didn't come across like that, from reading
> your book (which really is great by the way) with json not having the
> HFactors built in and going for a general style like you have it is not
> going to fit every problem but will work for many, we get that, its clearly
> outlined in the chapter where you introduce it.
> We have implemented the formatter, so the promise was there and we took
> it, and we have a very basic implementation outputting collection+json and
> the data fits, and will continue to fit moving forwards, if we add things
> the API will evolve and version-ing in this instance shouldn't be an issue
> as everything is discoverable, and for that you have done a really great
> job. Its just when we started implementing a simple client, we just seemed
> to lose the object style we are used too. Some of this is down to
> understanding as well, because we are trying to shift the mindset from
> human API's to an API for everything, machine and all, and that is
> sometimes the difficult notion to wrap your head around, even if the
> concept is simple when you read it out loud.
> We are new to this, and the number of "REST"ish apis that are around have
> probably clouded the judgement because they are all focused on the object
> being the resource (model to resource direct mapping) as they pan out their
> REST philosophy, when i guess the switch has to be from a point of view of
> the resources being agnostic and discoverable, which with collection+json
> they are and a truer representation or REST.
> We are looking at Hal at the moment, comparing the two and see which will
> fit our problem that little bit better (we may stick with collection+json
> or use both :))
> Great to have all the leaders in this field actively come and comment,
> really is a great boost for people to further their knowledge.
> Rob
> On Wednesday, November 21, 2012 9:00:50 PM UTC, Mike Amundsen wrote:
>> Jumping in here...
>> the biggest challenge (some would say drawback) to using my
>> Collection+JSON media type is that it was specifically designed to "break
>> the back" of object-style serializers in code libraries<g>.
>> I find that facing the notion of switching communications between
>> machines from object-oriented to state-oriented can be enlightening, even
>> if it turns out that's not what you decide to do for your project.
>> I think HAL does a very good job of providing hypermedia affordances
>> while still supporting object-style message passing. Be sure to check that
>> one out, too. It's also possible Siren would be a good fit, but I've not
>> built much w/ that one yet.
>> On Wed, Nov 21, 2012 at 3:43 PM, Roberto Modica <r...@modika.co.uk>wrote:
>>> Hi Glenn,
>>> Great talk, its nice to have a higher level representation of this
>>> stuff, with all the specs, dissertations etc. it sometimes gets a bit
>>> heave, this video has given me some inspiration of the node based
>>> Hypermedia API we are building at the start-up i am involved in.
>>> Also nice to see some great stuff coming out of Microsoft, Web API looks
>>> great.
>>> Collection+Json is the main Media type in the talk, and i have read
>>> about that in Mikes book , and even began to implement it(we created the
>>> formatter to deal with the general output) but it started to get a little
>>> verbose for us, especially when working with javascript and you losing the
>>> .notation to interact with the data for each object and having everything
>>> output as essentially a name value pair...
>>> Rob
>>> On Monday, November 12, 2012 10:10:06 AM UTC+1, Glenn Block wrote:
>>>> Hi folks
>>>> I recently delivered a talk on building hypermedia systems with ASP.NETWeb API. It is online here:
>>>> http://vimeo.com/**5326170**7 <http://vimeo.com/53261707>. The talk is
>>>> in two main parts with the first focusing on the what and why of Hypermedia
>>>> and the second on approaches.
>>>> Feedback welcome.
>>>> Glenn
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "API Craft" group.
>>> To unsubscribe from this group, send email to api-craft+...@**
>>> googlegroups.com.
>> --
> You received this message because you are subscribed to the Google Groups
> "API Craft" group.
> To unsubscribe from this group, send email to
> api-craft+unsubscribe@googlegroups.com.
> Visit this group at http://groups.google.com/group/api-craft?hl=en.
Mike, I like the fact that collection+json leads away from pure object
serialization toward more loose data. It works fine with web api, and in
this case I constructed types to for the message structure.
On Thu, Nov 22, 2012 at 5:19 AM, mca <m...@amundsen.com> wrote:
> Roberto:
> totally understand where you are coming from here. no need to apologize,
> etc. your observations are spot on and this is a great forum for discussing
> the pros/cons of any design when implementing a real-life solution.
> keep up the good work and continue to post here as there are lots of folks
> who are interested in the details (good and bad) arising from a real-life
> implementation.
> On Thu, Nov 22, 2012 at 4:28 AM, Roberto Modica <r...@modika.co.uk> wrote:
>> Hi Mike,
>> It wasn't a criticism, hope it didn't come across like that, from reading
>> your book (which really is great by the way) with json not having the
>> HFactors built in and going for a general style like you have it is not
>> going to fit every problem but will work for many, we get that, its clearly
>> outlined in the chapter where you introduce it.
>> We have implemented the formatter, so the promise was there and we took
>> it, and we have a very basic implementation outputting collection+json and
>> the data fits, and will continue to fit moving forwards, if we add things
>> the API will evolve and version-ing in this instance shouldn't be an issue
>> as everything is discoverable, and for that you have done a really great
>> job. Its just when we started implementing a simple client, we just seemed
>> to lose the object style we are used too. Some of this is down to
>> understanding as well, because we are trying to shift the mindset from
>> human API's to an API for everything, machine and all, and that is
>> sometimes the difficult notion to wrap your head around, even if the
>> concept is simple when you read it out loud.
>> We are new to this, and the number of "REST"ish apis that are around have
>> probably clouded the judgement because they are all focused on the object
>> being the resource (model to resource direct mapping) as they pan out their
>> REST philosophy, when i guess the switch has to be from a point of view of
>> the resources being agnostic and discoverable, which with collection+json
>> they are and a truer representation or REST.
>> We are looking at Hal at the moment, comparing the two and see which will
>> fit our problem that little bit better (we may stick with collection+json
>> or use both :))
>> Great to have all the leaders in this field actively come and comment,
>> really is a great boost for people to further their knowledge.
>> Rob
>> On Wednesday, November 21, 2012 9:00:50 PM UTC, Mike Amundsen wrote:
>>> Jumping in here...
>>> the biggest challenge (some would say drawback) to using my
>>> Collection+JSON media type is that it was specifically designed to "break
>>> the back" of object-style serializers in code libraries<g>.
>>> I find that facing the notion of switching communications between
>>> machines from object-oriented to state-oriented can be enlightening, even
>>> if it turns out that's not what you decide to do for your project.
>>> I think HAL does a very good job of providing hypermedia affordances
>>> while still supporting object-style message passing. Be sure to check that
>>> one out, too. It's also possible Siren would be a good fit, but I've not
>>> built much w/ that one yet.
>>> On Wed, Nov 21, 2012 at 3:43 PM, Roberto Modica <r...@modika.co.uk>wrote:
>>>> Hi Glenn,
>>>> Great talk, its nice to have a higher level representation of this
>>>> stuff, with all the specs, dissertations etc. it sometimes gets a bit
>>>> heave, this video has given me some inspiration of the node based
>>>> Hypermedia API we are building at the start-up i am involved in.
>>>> Also nice to see some great stuff coming out of Microsoft, Web API
>>>> looks great.
>>>> Collection+Json is the main Media type in the talk, and i have read
>>>> about that in Mikes book , and even began to implement it(we created the
>>>> formatter to deal with the general output) but it started to get a little
>>>> verbose for us, especially when working with javascript and you losing the
>>>> .notation to interact with the data for each object and having everything
>>>> output as essentially a name value pair...
>>>> Rob
>>>> On Monday, November 12, 2012 10:10:06 AM UTC+1, Glenn Block wrote:
>>>>> Hi folks
>>>>> I recently delivered a talk on building hypermedia systems with
>>>>> ASP.NET Web API. It is online here: http://vimeo.com/**5326170**7<http://vimeo.com/53261707>.
>>>>> The talk is in two main parts with the first focusing on the what and why
>>>>> of Hypermedia and the second on approaches.
>>>>> Feedback welcome.
>>>>> Glenn
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "API Craft" group.
>>>> To unsubscribe from this group, send email to api-craft+...@**
>>>> googlegroups.com.
>>> --
>> You received this message because you are subscribed to the Google Groups
>> "API Craft" group.
>> To unsubscribe from this group, send email to
>> api-craft+unsubscribe@googlegroups.com.
>> Visit this group at http://groups.google.com/group/api-craft?hl=en.
> --
> You received this message because you are subscribed to the Google Groups
> "API Craft" group.
> To unsubscribe from this group, send email to
> api-craft+unsubscribe@googlegroups.com.
> Visit this group at http://groups.google.com/group/api-craft?hl=en.
As to the whole debate of using messages vs objects, this same debate has
been going on since the SOAP days, as in the early days SOAP was RPC, but
it later evolved into a message / state based protocol, though most vendors
never really go t on board with that model.
On Thu, Nov 22, 2012 at 1:11 PM, Glenn Block <glenn.bl...@gmail.com> wrote:
> Sorry i am late to the convo.
> Roberto, glad to help.
> Mike, I like the fact that collection+json leads away from pure object
> serialization toward more loose data. It works fine with web api, and in
> this case I constructed types to for the message structure.
> On Thu, Nov 22, 2012 at 5:19 AM, mca <m...@amundsen.com> wrote:
>> Roberto:
>> totally understand where you are coming from here. no need to apologize,
>> etc. your observations are spot on and this is a great forum for discussing
>> the pros/cons of any design when implementing a real-life solution.
>> keep up the good work and continue to post here as there are lots of
>> folks who are interested in the details (good and bad) arising from a
>> real-life implementation.
>> On Thu, Nov 22, 2012 at 4:28 AM, Roberto Modica <r...@modika.co.uk> wrote:
>>> Hi Mike,
>>> It wasn't a criticism, hope it didn't come across like that, from
>>> reading your book (which really is great by the way) with json not having
>>> the HFactors built in and going for a general style like you have it is
>>> not going to fit every problem but will work for many, we get that, its
>>> clearly outlined in the chapter where you introduce it.
>>> We have implemented the formatter, so the promise was there and we took
>>> it, and we have a very basic implementation outputting collection+json and
>>> the data fits, and will continue to fit moving forwards, if we add things
>>> the API will evolve and version-ing in this instance shouldn't be an issue
>>> as everything is discoverable, and for that you have done a really great
>>> job. Its just when we started implementing a simple client, we just seemed
>>> to lose the object style we are used too. Some of this is down to
>>> understanding as well, because we are trying to shift the mindset from
>>> human API's to an API for everything, machine and all, and that is
>>> sometimes the difficult notion to wrap your head around, even if the
>>> concept is simple when you read it out loud.
>>> We are new to this, and the number of "REST"ish apis that are around
>>> have probably clouded the judgement because they are all focused on the
>>> object being the resource (model to resource direct mapping) as they pan
>>> out their REST philosophy, when i guess the switch has to be from a point
>>> of view of the resources being agnostic and discoverable, which with
>>> collection+json they are and a truer representation or REST.
>>> We are looking at Hal at the moment, comparing the two and see which
>>> will fit our problem that little bit better (we may stick with
>>> collection+json or use both :))
>>> Great to have all the leaders in this field actively come and comment,
>>> really is a great boost for people to further their knowledge.
>>> Rob
>>> On Wednesday, November 21, 2012 9:00:50 PM UTC, Mike Amundsen wrote:
>>>> Jumping in here...
>>>> the biggest challenge (some would say drawback) to using my
>>>> Collection+JSON media type is that it was specifically designed to "break
>>>> the back" of object-style serializers in code libraries<g>.
>>>> I find that facing the notion of switching communications between
>>>> machines from object-oriented to state-oriented can be enlightening, even
>>>> if it turns out that's not what you decide to do for your project.
>>>> I think HAL does a very good job of providing hypermedia affordances
>>>> while still supporting object-style message passing. Be sure to check that
>>>> one out, too. It's also possible Siren would be a good fit, but I've not
>>>> built much w/ that one yet.
>>>> On Wed, Nov 21, 2012 at 3:43 PM, Roberto Modica <r...@modika.co.uk>wrote:
>>>>> Hi Glenn,
>>>>> Great talk, its nice to have a higher level representation of this
>>>>> stuff, with all the specs, dissertations etc. it sometimes gets a bit
>>>>> heave, this video has given me some inspiration of the node based
>>>>> Hypermedia API we are building at the start-up i am involved in.
>>>>> Also nice to see some great stuff coming out of Microsoft, Web API
>>>>> looks great.
>>>>> Collection+Json is the main Media type in the talk, and i have read
>>>>> about that in Mikes book , and even began to implement it(we created the
>>>>> formatter to deal with the general output) but it started to get a little
>>>>> verbose for us, especially when working with javascript and you losing the
>>>>> .notation to interact with the data for each object and having everything
>>>>> output as essentially a name value pair...
>>>>> Rob
>>>>> On Monday, November 12, 2012 10:10:06 AM UTC+1, Glenn Block wrote:
>>>>>> Hi folks
>>>>>> I recently delivered a talk on building hypermedia systems with
>>>>>> ASP.NET Web API. It is online here: http://vimeo.com/**5326170**7<http://vimeo.com/53261707>.
>>>>>> The talk is in two main parts with the first focusing on the what and why
>>>>>> of Hypermedia and the second on approaches.
>>>>>> Feedback welcome.
>>>>>> Glenn
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "API Craft" group.
>>>>> To unsubscribe from this group, send email to api-craft+...@**
>>>>> googlegroups.com.
>>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "API Craft" group.
>>> To unsubscribe from this group, send email to
>>> api-craft+unsubscribe@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/api-craft?hl=en.
>> --
>> You received this message because you are subscribed to the Google Groups
>> "API Craft" group.
>> To unsubscribe from this group, send email to
>> api-craft+unsubscribe@googlegroups.com.
>> Visit this group at http://groups.google.com/group/api-craft?hl=en.
On 22 Nov 2012, at 18:11, Glenn Block <glenn.bl...@gmail.com> wrote:
> Sorry i am late to the convo.
> Roberto, glad to help.
> Mike, I like the fact that collection+json leads away from pure object serialization toward more loose data. It works fine with web api, and in this case I constructed types to for the message structure.
Hi Glenn,
Can you clarify what you mean here I'm not sure I get it!
> On 22 Nov 2012, at 18:11, Glenn Block <glenn.bl...@gmail.com> wrote:
>> Sorry i am late to the convo.
>> Roberto, glad to help.
>> Mike, I like the fact that collection+json leads away from pure object
>> serialization toward more loose data. It works fine with web api, and in
>> this case I constructed types to for the message structure.
> Hi Glenn,
> Can you clarify what you mean here I'm not sure I get it!
> Cheers,
> M
> --
> You received this message because you are subscribed to the Google Groups
> "API Craft" group.
> To unsubscribe from this group, send email to
> api-craft+unsubscribe@googlegroups.com.
> Visit this group at http://groups.google.com/group/api-craft?hl=en.
On Fri, Nov 23, 2012 at 4:10 PM, Glenn Block <glenn.bl...@gmail.com> wrote:
> Which part?
> On 11/23/12, Mike Kelly <mikekelly...@gmail.com> wrote:
>> On 22 Nov 2012, at 18:11, Glenn Block <glenn.bl...@gmail.com> wrote:
>>> Sorry i am late to the convo.
>>> Roberto, glad to help.
>>> Mike, I like the fact that collection+json leads away from pure object
>>> serialization toward more loose data. It works fine with web api, and in
>>> this case I constructed types to for the message structure.
>> Hi Glenn,
>> Can you clarify what you mean here I'm not sure I get it!
>> Cheers,
>> M
>> --
>> You received this message because you are subscribed to the Google Groups
>> "API Craft" group.
>> To unsubscribe from this group, send email to
>> api-craft+unsubscribe@googlegroups.com.
>> Visit this group at http://groups.google.com/group/api-craft?hl=en.
> --
> You received this message because you are subscribed to the Google Groups "API Craft" group.
> To unsubscribe from this group, send email to api-craft+unsubscribe@googlegroups.com.
> Visit this group at http://groups.google.com/group/api-craft?hl=en.
On Fri, Nov 23, 2012 at 4:22 PM, Glenn Block <glenn.bl...@gmail.com> wrote:
> Meaning collection+json uses key-value for data transfer.
> --
> You received this message because you are subscribed to the Google Groups "API Craft" group.
> To unsubscribe from this group, send email to api-craft+unsubscribe@googlegroups.com.
> Visit this group at http://groups.google.com/group/api-craft?hl=en.
> a JSON object is key-value anyway though.. right?
> On Fri, Nov 23, 2012 at 4:22 PM, Glenn Block <glenn.bl...@gmail.com> wrote:
>> Meaning collection+json uses key-value for data transfer.
>> --
>> You received this message because you are subscribed to the Google Groups
>> "API Craft" group.
>> To unsubscribe from this group, send email to
>> api-craft+unsubscribe@googlegroups.com.
>> Visit this group at http://groups.google.com/group/api-craft?hl=en.
> --
> You received this message because you are subscribed to the Google Groups
> "API Craft" group.
> To unsubscribe from this group, send email to
> api-craft+unsubscribe@googlegroups.com.
> Visit this group at http://groups.google.com/group/api-craft?hl=en.
> a JSON object is key-value anyway though.. right?
> On Fri, Nov 23, 2012 at 4:22 PM, Glenn Block <glenn.bl...@gmail.com> wrote:
>> Meaning collection+json uses key-value for data transfer.
>> --
>> You received this message because you are subscribed to the Google Groups
>> "API Craft" group.
>> To unsubscribe from this group, send email to
>> api-craft+unsubscribe@googlegroups.com.
>> Visit this group at http://groups.google.com/group/api-craft?hl=en.
> --
> You received this message because you are subscribed to the Google Groups
> "API Craft" group.
> To unsubscribe from this group, send email to
> api-craft+unsubscribe@googlegroups.com.
> Visit this group at http://groups.google.com/group/api-craft?hl=en.
ok. if that's not the point - what is the point? :)
in other words: what's the connection between "preventing nested k/v
heirarchies in JSON" and "leading away from pure object serialization
toward more loose data"?
On Sat, Nov 24, 2012 at 12:12 AM, Glenn Block <glenn.bl...@gmail.com> wrote:
> Actually it us not simple key-value, it is a nested hierarchy of key-values.
> On 11/23/12, Mike Kelly <mikekelly...@gmail.com> wrote:
>> a JSON object is key-value anyway though.. right?
>> On Fri, Nov 23, 2012 at 4:22 PM, Glenn Block <glenn.bl...@gmail.com> wrote:
>>> Meaning collection+json uses key-value for data transfer.
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "API Craft" group.
>>> To unsubscribe from this group, send email to
>>> api-craft+unsubscribe@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/api-craft?hl=en.
>> --
>> You received this message because you are subscribed to the Google Groups
>> "API Craft" group.
>> To unsubscribe from this group, send email to
>> api-craft+unsubscribe@googlegroups.com.
>> Visit this group at http://groups.google.com/group/api-craft?hl=en.
> --
> You received this message because you are subscribed to the Google Groups "API Craft" group.
> To unsubscribe from this group, send email to api-craft+unsubscribe@googlegroups.com.
> Visit this group at http://groups.google.com/group/api-craft?hl=en.
I think the point is that Mike A is discouraging a style where you simply
pass your application objects bi-directionally over the wire using a
serializer. Instead it encourages extracting data elements / decoupling
from the implementation.
On Friday, November 23, 2012, Mike Kelly wrote:
> ok. if that's not the point - what is the point? :)
> in other words: what's the connection between "preventing nested k/v
> heirarchies in JSON" and "leading away from pure object serialization
> toward more loose data"?
> Cheers,
> M
> On Sat, Nov 24, 2012 at 12:12 AM, Glenn Block <glenn.bl...@gmail.com<javascript:;>>
> wrote:
> > Actually it us not simple key-value, it is a nested hierarchy of
> key-values.
> > On 11/23/12, Mike Kelly <mikekelly...@gmail.com <javascript:;>> wrote:
> >> a JSON object is key-value anyway though.. right?
> >> On Fri, Nov 23, 2012 at 4:22 PM, Glenn Block <glenn.bl...@gmail.com<javascript:;>>
> wrote:
> >>> Meaning collection+json uses key-value for data transfer.
> >>> --
> >>> You received this message because you are subscribed to the Google
> Groups
> >>> "API Craft" group.
> >>> To unsubscribe from this group, send email to
> >>> api-craft+unsubscribe@googlegroups.com <javascript:;>.
> >>> Visit this group at http://groups.google.com/group/api-craft?hl=en.
> >> --
> >> You received this message because you are subscribed to the Google
> Groups
> >> "API Craft" group.
> >> To unsubscribe from this group, send email to
> >> api-craft+unsubscribe@googlegroups.com <javascript:;>.
> >> Visit this group at http://groups.google.com/group/api-craft?hl=en.
> > --
> > You received this message because you are subscribed to the Google
> Groups "API Craft" group.
> > To unsubscribe from this group, send email to
> api-craft+unsubscribe@googlegroups.com <javascript:;>.
> > Visit this group at http://groups.google.com/group/api-craft?hl=en.
> --
> You received this message because you are subscribed to the Google Groups
> "API Craft" group.
> To unsubscribe from this group, send email to
> api-craft+unsubscribe@googlegroups.com <javascript:;>.
> Visit this group at http://groups.google.com/group/api-craft?hl=en.
On Sat, Nov 24, 2012 at 11:47 AM, Glenn Block <glenn.bl...@gmail.com> wrote:
> I think the point is that Mike A is discouraging a style where you simply
> pass your application objects bi-directionally over the wire using a
> serializer. Instead it encourages extracting data elements / decoupling from
> the implementation.
Afaict, decoupling is mainly encouraged here because the transfer of
information between client and server is driven through a given media
type (i.e. the uniform interface constraint). In this case you have
picked mamund's cj, but this principal applies equally to other media
types such as hal+json, siren, etc.
I think clunkiness or friction between a given media type and an
"implementation" might force some decoupling to be put in place (i.e.
resurrecting the V in your MVC frameworks for your APIs), but that
specific type of decoupling is behind the interface and internal to a
client or server - so it's not related to decoupling between client
and server. Also, one obvious consideration/trade-off here is that
more friction means a degraded user experience (where a user is a
developer), which may or may not be ok depending on how you feel about
encouraging adoption, learning curves, developer productivity, etc.
It doesn't take too much 'twiddly bits' in a media type to add enough
friction to render basic object serialization unsuitable. For example,
hal+json has maintained the full richness of the JSON object model,
and yet we have View/templating libraries for it across most major
programming languages[1]. Of course, I might be missing your point
here and that is not what you meant at all by 'decoupling from the
implementation'!
Mike I appreciate the work you've done with HAL, but you are a little too
dogmatic / religious in your defense of it. I don't think it's necessary
every time hypermedia or media types are mentioned that one needs to affirm
or deny, or defend their statements based on HAL's existence. It is a fine
format, but there is life after HAL.
On Saturday, November 24, 2012, Mike Kelly wrote:
> On Sat, Nov 24, 2012 at 11:47 AM, Glenn Block <glenn.bl...@gmail.com<javascript:;>>
> wrote:
> > I think the point is that Mike A is discouraging a style where you simply
> > pass your application objects bi-directionally over the wire using a
> > serializer. Instead it encourages extracting data elements / decoupling
> from
> > the implementation.
> Afaict, decoupling is mainly encouraged here because the transfer of
> information between client and server is driven through a given media
> type (i.e. the uniform interface constraint). In this case you have
> picked mamund's cj, but this principal applies equally to other media
> types such as hal+json, siren, etc.
> I think clunkiness or friction between a given media type and an
> "implementation" might force some decoupling to be put in place (i.e.
> resurrecting the V in your MVC frameworks for your APIs), but that
> specific type of decoupling is behind the interface and internal to a
> client or server - so it's not related to decoupling between client
> and server. Also, one obvious consideration/trade-off here is that
> more friction means a degraded user experience (where a user is a
> developer), which may or may not be ok depending on how you feel about
> encouraging adoption, learning curves, developer productivity, etc.
> It doesn't take too much 'twiddly bits' in a media type to add enough
> friction to render basic object serialization unsuitable. For example,
> hal+json has maintained the full richness of the JSON object model,
> and yet we have View/templating libraries for it across most major
> programming languages[1]. Of course, I might be missing your point
> here and that is not what you meant at all by 'decoupling from the
> implementation'!
> --
> You received this message because you are subscribed to the Google Groups
> "API Craft" group.
> To unsubscribe from this group, send email to
> api-craft+unsubscribe@googlegroups.com <javascript:;>.
> Visit this group at http://groups.google.com/group/api-craft?hl=en.
> Mike I appreciate the work you've done with HAL, but you are a little too dogmatic / religious in your defense of it. I don't think it's necessary every time hypermedia or media types are mentioned that one needs to affirm or deny, or defend their statements based on HAL's existence. It is a fine format, but there is life after HAL.
> Get over it.
> On Saturday, November 24, 2012, Mike Kelly wrote:
> On Sat, Nov 24, 2012 at 11:47 AM, Glenn Block <glenn.bl...@gmail.com> wrote:
> > I think the point is that Mike A is discouraging a style where you simply
> > pass your application objects bi-directionally over the wire using a
> > serializer. Instead it encourages extracting data elements / decoupling from
> > the implementation.
> Afaict, decoupling is mainly encouraged here because the transfer of
> information between client and server is driven through a given media
> type (i.e. the uniform interface constraint). In this case you have
> picked mamund's cj, but this principal applies equally to other media
> types such as hal+json, siren, etc.
> I think clunkiness or friction between a given media type and an
> "implementation" might force some decoupling to be put in place (i.e.
> resurrecting the V in your MVC frameworks for your APIs), but that
> specific type of decoupling is behind the interface and internal to a
> client or server - so it's not related to decoupling between client
> and server. Also, one obvious consideration/trade-off here is that
> more friction means a degraded user experience (where a user is a
> developer), which may or may not be ok depending on how you feel about
> encouraging adoption, learning curves, developer productivity, etc.
> It doesn't take too much 'twiddly bits' in a media type to add enough
> friction to render basic object serialization unsuitable. For example,
> hal+json has maintained the full richness of the JSON object model,
> and yet we have View/templating libraries for it across most major
> programming languages[1]. Of course, I might be missing your point
> here and that is not what you meant at all by 'decoupling from the
> implementation'!
> --
> You received this message because you are subscribed to the Google Groups "API Craft" group.
> To unsubscribe from this group, send email to api-craft+unsubscribe@googlegroups.com.
> Visit this group at http://groups.google.com/group/api-craft?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "API Craft" group.
> To unsubscribe from this group, send email to api-craft+unsubscribe@googlegroups.com.
> Visit this group at http://groups.google.com/group/api-craft?hl=en.
It does seem like a thread that you could have stayed out of, Mike. HAL got mentioned early on and Glenn didn't make any effort to dismiss it. As a disinterested observer, that interjection seemed more than adequate for your visibility needs. But it seems that half of the responses to the thread were vague insinuations on your part.
How would you have felt if the tables were turned? Maybe you would have reacted more strongly. I admire his diplomacy in the situation.
This isn't a war. The community will make a de-facto decision on which effort is more viable, and it's always a great thing when there are multiple options under active development. Directly interested parties are better off focusing on the benefits of their own techniques, improving them as they see opportunity. If other techniques are suboptimal, align your messaging to make it clear that your techniques solve a problem other techniques don't even realize they have. Users will gravitate toward those positives much more loyally than they will to less positive messaging.
$0.02...
On Nov 24, 2012, at 2:51 PM, Mike Kelly <mikekelly...@gmail.com> wrote:
> With all due respect I couldn't give a monkies about your meta-objections to the points I make.
> Next time you don't have a direct response to make, it's more efficient for everyone if you just don't reply.
> Cheers,
> M
> On 24 Nov 2012, at 19:00, Glenn Block <glenn.bl...@gmail.com> wrote:
>> Mike I appreciate the work you've done with HAL, but you are a little too dogmatic / religious in your defense of it. I don't think it's necessary every time hypermedia or media types are mentioned that one needs to affirm or deny, or defend their statements based on HAL's existence. It is a fine format, but there is life after HAL.
>> Get over it.
>> On Saturday, November 24, 2012, Mike Kelly wrote:
>> On Sat, Nov 24, 2012 at 11:47 AM, Glenn Block <glenn.bl...@gmail.com> wrote:
>> > I think the point is that Mike A is discouraging a style where you simply
>> > pass your application objects bi-directionally over the wire using a
>> > serializer. Instead it encourages extracting data elements / decoupling from
>> > the implementation.
>> Afaict, decoupling is mainly encouraged here because the transfer of
>> information between client and server is driven through a given media
>> type (i.e. the uniform interface constraint). In this case you have
>> picked mamund's cj, but this principal applies equally to other media
>> types such as hal+json, siren, etc.
>> I think clunkiness or friction between a given media type and an
>> "implementation" might force some decoupling to be put in place (i.e.
>> resurrecting the V in your MVC frameworks for your APIs), but that
>> specific type of decoupling is behind the interface and internal to a
>> client or server - so it's not related to decoupling between client
>> and server. Also, one obvious consideration/trade-off here is that
>> more friction means a degraded user experience (where a user is a
>> developer), which may or may not be ok depending on how you feel about
>> encouraging adoption, learning curves, developer productivity, etc.
>> It doesn't take too much 'twiddly bits' in a media type to add enough
>> friction to render basic object serialization unsuitable. For example,
>> hal+json has maintained the full richness of the JSON object model,
>> and yet we have View/templating libraries for it across most major
>> programming languages[1]. Of course, I might be missing your point
>> here and that is not what you meant at all by 'decoupling from the
>> implementation'!
>> --
>> You received this message because you are subscribed to the Google Groups "API Craft" group.
>> To unsubscribe from this group, send email to api-craft+unsubscribe@googlegroups.com.
>> Visit this group at http://groups.google.com/group/api-craft?hl=en.
>> -- >> You received this message because you are subscribed to the Google Groups "API Craft" group.
>> To unsubscribe from this group, send email to api-craft+unsubscribe@googlegroups.com.
>> Visit this group at http://groups.google.com/group/api-craft?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "API Craft" group.
> To unsubscribe from this group, send email to api-craft+unsubscribe@googlegroups.com.
> Visit this group at http://groups.google.com/group/api-craft?hl=en.
My two cents worth is I was surprised by both Glenn and your reactions Brian. I didn't think Mike's contribution was over the line; I found value in what he said. And I'm not pro or con HAL. IMO anyway.
-Mike
On Nov 24, 2012, at 4:22 PM, Brian Topping <topp...@codehaus.org> wrote:
> It does seem like a thread that you could have stayed out of, Mike. HAL got mentioned early on and Glenn didn't make any effort to dismiss it. As a disinterested observer, that interjection seemed more than adequate for your visibility needs. But it seems that half of the responses to the thread were vague insinuations on your part.
> How would you have felt if the tables were turned? Maybe you would have reacted more strongly. I admire his diplomacy in the situation.
> This isn't a war. The community will make a de-facto decision on which effort is more viable, and it's always a great thing when there are multiple options under active development. Directly interested parties are better off focusing on the benefits of their own techniques, improving them as they see opportunity. If other techniques are suboptimal, align your messaging to make it clear that your techniques solve a problem other techniques don't even realize they have. Users will gravitate toward those positives much more loyally than they will to less positive messaging.
> $0.02...
> On Nov 24, 2012, at 2:51 PM, Mike Kelly <mikekelly...@gmail.com> wrote:
>> With all due respect I couldn't give a monkies about your meta-objections to the points I make.
>> Next time you don't have a direct response to make, it's more efficient for everyone if you just don't reply.
>> Cheers,
>> M
>> On 24 Nov 2012, at 19:00, Glenn Block <glenn.bl...@gmail.com> wrote:
>>> Mike I appreciate the work you've done with HAL, but you are a little too dogmatic / religious in your defense of it. I don't think it's necessary every time hypermedia or media types are mentioned that one needs to affirm or deny, or defend their statements based on HAL's existence. It is a fine format, but there is life after HAL.
>>> Get over it.
>>> On Saturday, November 24, 2012, Mike Kelly wrote:
>>> On Sat, Nov 24, 2012 at 11:47 AM, Glenn Block <glenn.bl...@gmail.com> wrote:
>>> > I think the point is that Mike A is discouraging a style where you simply
>>> > pass your application objects bi-directionally over the wire using a
>>> > serializer. Instead it encourages extracting data elements / decoupling from
>>> > the implementation.
>>> Afaict, decoupling is mainly encouraged here because the transfer of
>>> information between client and server is driven through a given media
>>> type (i.e. the uniform interface constraint). In this case you have
>>> picked mamund's cj, but this principal applies equally to other media
>>> types such as hal+json, siren, etc.
>>> I think clunkiness or friction between a given media type and an
>>> "implementation" might force some decoupling to be put in place (i.e.
>>> resurrecting the V in your MVC frameworks for your APIs), but that
>>> specific type of decoupling is behind the interface and internal to a
>>> client or server - so it's not related to decoupling between client
>>> and server. Also, one obvious consideration/trade-off here is that
>>> more friction means a degraded user experience (where a user is a
>>> developer), which may or may not be ok depending on how you feel about
>>> encouraging adoption, learning curves, developer productivity, etc.
>>> It doesn't take too much 'twiddly bits' in a media type to add enough
>>> friction to render basic object serialization unsuitable. For example,
>>> hal+json has maintained the full richness of the JSON object model,
>>> and yet we have View/templating libraries for it across most major
>>> programming languages[1]. Of course, I might be missing your point
>>> here and that is not what you meant at all by 'decoupling from the
>>> implementation'!
>>> --
>>> You received this message because you are subscribed to the Google Groups "API Craft" group.
>>> To unsubscribe from this group, send email to api-craft+unsubscribe@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/api-craft?hl=en.
>>> -- >>> You received this message because you are subscribed to the Google Groups "API Craft" group.
>>> To unsubscribe from this group, send email to api-craft+unsubscribe@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/api-craft?hl=en.
>> -- >> You received this message because you are subscribed to the Google Groups "API Craft" group.
>> To unsubscribe from this group, send email to api-craft+unsubscribe@googlegroups.com.
>> Visit this group at http://groups.google.com/group/api-craft?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "API Craft" group.
> To unsubscribe from this group, send email to api-craft+unsubscribe@googlegroups.com.
> Visit this group at http://groups.google.com/group/api-craft?hl=en.
