RE: Let's get started

On Friday, June 28, 2013 4:13 PM, Kevin Swiber wrote:
> Hi.  I'm Kevin.
> 
> I've spent a good portion of my nerdy career tackling complexity in
> enterprise software during the day and building infrastructure
> software by night.  I've experimented with scaling both over a
> distributed architecture at various organizations.
> 
> I've had roles in software development, enterprise architecture,
> process improvement, and innovation.

Great to have you on board Kevin!


> I write open source software.  I like standards.  I used to have a
> giant heart around XMPP, but she stopped calling me.  I live near HTTP
> these days.

:-)


> [...]
> Hydra is interesting.  In Siren, I've begun using class values as sort
> of "type mixins."  An entity of a certain class contains attributes
> associated with that class definition.  This is similar to Hydra
> types, except without the Highlander principle applied.  In a Siren
> entity, there can be more than one.

You can have multiple classes in Hydra as well, if that's what you meant by
the Highlander principle :-) The only place where I'm not sure yet whether
it makes sense to allow multiple classes (and what that should mean) is
"expects" and "returns" in an operation.

I see you directly associate the fields to an action instead of going
through the indirection of a class in Siren. In Hydra, classes have
"supportedProperties" and those are used when you set "expects" of an
operation to a specific class. Currently, I would say that, if you set
"expects" to multiple classes, all their properties are known to be
supported. Does that make sense?


> Siren has actions.  Actions are named, like forms.  I think these are
> powerful.  I think Hydra maps "form inputs" to types in the
> vocabulary.  Siren doesn't do this.  Reasons why or why not to do this
> would make a good discussion.

Right. Hydra has an additional indirection as explained above. The rationale
behind that is that I assume that the same "form inputs" will be reused
quite often across the web. If that's true, everyone just needs to set
"expects" to the same URL, i.e., the URL identifying the class. The downside
is that it is slightly more complex.

This actually brings me to another question. Hydra has "operations" whereas
Siren has "actions". Activity Streams also has actions. So has the latest
schema.org proposal. I'm not a native speaker and don't really care how this
is called but I realized recently that almost everyone else calls these
things "actions" :-)

So the question is, should we renamed operations to actions in an effort to
align with other approaches?


> I feel we are on the brink of something truly incredible in the
> hypermedia space.  I believe in collaboration over competition.  It's
> too early to claim #WINNING.

+1


> In general, I would like to see discussion here put in terms of the
> _benefits_ REST provides, as opposed to subtleties in the definition
> of "What is RESTful?"  Ain't nobody got time for that!

+1 I'm not really interested in theoretical discussions. My goal is to
create a simple and practical solution that is generic enough to be used in
a broad range of application domains. Some complexity will be unavoidable
but if we build enough tooling around it, it doesn't matter that much.

Here are some things that I would like to see us discuss as well:
  - implementation in popular Web development frameworks (I have one for
Symfony2 which I'm refactoring at the moment)
  - clients in various programming languages
  - other tooling, e.g., conversion of a Hydra description in JSON-LD to a
nice looking HTML document
  - ... everything that simplifies web devs' lives :-P



--
Markus Lanthaler
@markuslanthaler

Received on Wednesday, 3 July 2013 12:30:34 UTC