A few comments

[fosrias]

Is it a correct MSON interpretation that you can't use rel with implementation details? It's either or?

Did you go back to reference_url vs. ref_url? Ideally avoid long names when there is a commonly accepted shorter version.

I think you can just use properties and note that they are request properties in the description.

Why no nested properties?

Not sure the limitation on one method per link per my prior comment. Think it is unnecessarily restrictive.

[smizell]

Is it a correct MSON interpretation that you can't use rel with implementation details? It's either or?

This is correct. It's deferring all implementation details to the link relation somewhere else. However, I can be persuaded otherwise so long that it's simple. I think you run into complexity when the implementation details would conflict with link relation details.

Did you go back to reference_url vs. ref_url? Ideally avoid long names when there is a commonly accepted shorter version.

I did, only because it was the only property in the entire spec that was shortened. Maybe it's a way to differentiate from other specs? I don't feel strongly about this, but it did seem like an inconsistency.

I think you can just use properties and note that they are request properties in the description.

Agreed, sounds good to me.

Why no nested properties?

There is complexity around nesting properties IMO. What happens when you have a media type for encoding that doesn't support deep nesting (like x-www-form-urlencoded)? I may be overthinking this here. I could go either way here. Do you feel strongly about any direction?

One thing is that most hypermedia formats that use forms do not allow for nested properties (see Siren, Collection+JSON, UBER, etc.)

Not sure the limitation on one method per link per my prior comment. Think it is unnecessarily restrictive.

Don't think of it as "one method per link" but rather "one affordance per link." If you had multiple affordances per link, you'd have to give names to those affordances apart from implementation details, and then it just feels odd and complex.

Consider how link hints works. What do these different methods mean from an affordance perspective?

This can all be simpler and more granular with one affordance per link. I think it grows in complexity as you move toward link hints. The way out of this is come up with an external link relation and use the rel property to link to it.

[fosrias]

So, IIUC rel does not imply implementation details and using a defined IANA rel in particular. Custom rels could link to a profile but I think in general, allowing to specify a rel on a link always makes sense.

I would still do ref_url. It's just unnecessarily long and pretty much everyone will get it as reference, IMO.

W/r to nested properties, I would still allow it, but if you use an encode_as that would not support it, then you should not nest.

Railsesque is fine by me on naming.

I think we should keep the word affordance out of this. Not in the spirit of RJ to use those kinds of terms, so may 'affordance' => 'related set of actions' or something. Further, you just be more detailed if you have to but if you don't you can take a minimalistic approach.

I do think that encode_as and method should accept a range of values. Either arrays or comma-delimited strings.

[smizell]

So, IIUC rel does not imply implementation details and using a defined IANA rel in particular. Custom rels could link to a profile but I think in general, allowing to specify a rel on a link always makes sense.

I just want to make sure, are you agreeing with me that I'm delegating implementation details to the link relation?

I would still do ref_url. It's just unnecessarily long and pretty much everyone will get it as reference, IMO.

Sounds good.

W/r to nested properties, I would still allow it,

In thinking more about it, it's a little bit of a rabbit hole. I'd like to push here that we keep it like it is and then if we find it needs more, we should allow for nesting or linking to schemas. In other words, let's go with the simple, existing pattern and see what happens with it. What do you think?

I think we should keep the word affordance out of this.

Noted, good idea.

I do think that encode_as and method should accept a range of values. Either arrays or comma-delimited strings.

I think I am with you for encode_as but I need more convincing for method as multiple values. To expand more on this, consider the edit link relation type here. Note how the single link relation allows for "read, update, and deleted," and how those related to specific methods in the spec.

For us to define a link relation like this, we would need to nest "actions." As in, the edit link allows for read, update, and delete. This makes sense when you have many actions for one link, but when you just have one it seems like overkill.

If you moved away from naming each action, you'd end up with an array of methods that say, "The edit link supports GET, POST, and DELETE." This doesn't really tell you anything about the individual actions for those methods. This doesn't seem like a win to me for simplicity.

Note how Mike Amundsen breaks edit into four actions here. You can read more about this discussion here

The only way to make this work in my mind is that with multiple methods you're saying they mean the exact same thing. As in, an edit link with PUT and POST for methods means you can use either method. But this is not something you see in any other format.

So I've rambled here to say that I still don't see what applying multiple methods to a single link gets you. It would be similar to having multiple methods for an HTML <form> IMO.

[fosrias]

I just want to make sure, are you agreeing with me that I'm delegating implementation details to the link relation?

I am disagreeing. rel does not universally include implementation details, IIUC.

How would you define something like edit in this profile that supports multiple methods?

[fosrias]

Also, other than implementation is there anything this does that a JSON version of ALPS does not do?

[smizell]

rel does not universally include implementation details, IIUC.

This is true. I'll move it to allow for implementation details.

How would you define something like edit in this profile that supports multiple methods?

You would have to define the actions separately OR define a custom link relation type OR use a registered link relation. Summary of my problems:

• Multiple methods on a single link do not convey the semantics for each action.
• Adding multiple actions under a single link seems to add complexity to cover edge cases

Think of links as either a <a> tag or <form> tag in HTML. One action. This is of course constraining link relations, but IMO it's easier to design and reason about to keep it all simple.

Also, other than implementation is there anything this does that a JSON version of ALPS does not do?

I think the difference here is that we are mapping directly to a model, whereas ALPS is meant to be model-agnostic. ALPS requires mapping from ALPS to another media type, whereas this doesn't. With this and some implementation details, you get an interesting mix of simplicity. I think this is easily mapped to ALPS, so you can get the best of both worlds if that's what you're wanting.

Of course, the goal in my mind is to make stepping stones to full-on solutions. Making a separate spec like this might not be necessary to fulfill the same concepts we have here. I'm with you there.

[smizell]

One more note on "multiple methods per link."

Let's say there is a customer who is related to a collection orders. This relationship is expressed by a link for orders that can be found under customer.

If we were to provide multiple methods for that orders link, it might be GET and POST. However, POST would be for a different action create, so in the context of the original link it is out of place. It would be better to define a create link on the orders collection with a single POST method.

In a scenario where people are linking to resources, there is the trend to think of the methods available on that resource. However, it would be better to think about state transitions that should be tied to a single method.

Just an example, hope it helps share my point of view.