Extensions

[Michael Tiller]

I've posted a few ideas here that haven't gotten any traction.  And that is fine.  I completely get the idea that Siren should stay simple.

But it would be nice if there were a formal way to extend Siren.  It seems that it would be good to at least specify in the Siren spec how extensions should be made, a means to register extensions (e.g., to avoid name collisions) and a means to indicate what extensions are supported by a server.

Thoughts?

--

Mike

[Kevin Swiber]

This is an important topic.  Thanks for raising it, Mike.

I'd love to allow this in a nice, clean way.

A couple of questions:

1. What are some example extensions that would make sense?

2. How does an API advertise it's using an extension?  Should it advertise at all?

3. How do we allow an official registry of extensions but accommodate unofficial extensions, as well?  (Think of link relation names vs. URIs.)

Happy to entertain any thoughts in this area.

Thanks,

Kevin

--
You received this message because you are subscribed to the Google Groups "Siren Hypermedia" group.
To unsubscribe from this group and stop receiving emails from it, send an email to siren-hypermed...@googlegroups.com.
To post to this group, send email to siren-hy...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/siren-hypermedia/101e778d-8c6d-40e8-b118-da6aa018cc5a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[mca]

Great topic. Adding my opinoins below.

EXTENSIONS ARE IMPORTANT

Extensions is, IMO, an important feature of a vital media type format. it let's ppl fill in "missing things" w/o a lot of up front ceremony and ends up encouraging mods to the format that could eventually get rolled into the spec.

NO ADVERTISING

i've played w/ advertising extensions in responses (usually through a profile URI or a special rel="extension" URI) but have not found it much help. essentially, advertising for extensions is a way to allow clients to REJECT the response -- something I don't encourage.

MUST IGNORE

instead, i really push ppl to build clients with MUST IGNORE as a feature -- just ignore the stuff you don't understand. this keeps the number of accepted responses high without requiring clients to do something new if an extension shows up.

ALWAYS OPTIONAL, NEVER OVERRIDE  

the second leg of the MUST IGNORE pattern is to make all extensions OPTIONAL - IOW, clients are still fully compliant when they ignore extensions. This also means there is guidance that no extension can change any existing part of the spec (e.g. override or remove spec'd behaviors). 

NAMING CHALLENGE

In Cj, extensions can be a simple as a new name/value pair on an existing element on up to a new root-level object with lots of details below. I have a warning to name the elements uniquely, but (frankly) don't have a lot of enforcement control. not found a good way to enforce this w/o adding too high a bar for creating useful extensions.

REPO AS REGISTRY

finally, for Cj, i started using a repo for extensions. this is a low bar for entry and seems to work OK. 

cheers.

mca

Mike Amundsen

+1.859.757.1449
skype:mca.amundsen
http://amundsen.com/blog/
http://twitter.com/mamund
https://github.com/mamund
http://linkedin.com/in/mamund

To view this discussion on the web visit https://groups.google.com/d/msgid/siren-hypermedia/CAGA7vN65AphtV7gwums7HRWR3-c%3DOtHpUkKbg1BWedLwBj%2BOyA%40mail.gmail.com.

[Dietrich Schulten]

Hi Kevin,

Am Samstag, 23. April 2016 20:12:40 UTC+2 schrieb Kevin Swiber:

This is an important topic.  Thanks for raising it, Mike.

I'd love to allow this in a nice, clean way.

A couple of questions:

1. What are some example extensions that would make sense?

- Allow all html5 attributes of the input element as they become available, without forcing clients to support them. Define how minimizable attributes should be treated (I tend to use required=true)

- express request bodies with nested structures: dot-separated property paths?

- have a server-based autocomplete mechanism on the input field.

 

2. How does an API advertise it's using an extension?  Should it advertise at all?

Could really be an extensions folder with textual descriptions on Github following a certain template, with moderation by the committers, so that people do not invent many ways to solve the same problem.

 

3. How do we allow an official registry of extensions but accommodate unofficial extensions, as well?  (Think of link relation names vs. URIs.)

One more page with links to other extension documents.

 

- JsonApi just recently scrapped their original extension mechanism [1]. It might make sense to check what were their reasons. Does anyone know why they decided to start  over?

[1] http://jsonapi.org/extensions/