Optional extension?

[jonathanrobie]

Currently, DTS does not have optional extensions. If we introduce them, how does a client discover which extensions are supported on a given server?

An alternative would be to say that a client can always return a permission error - you aren't allowed to update this resource, but has to support the method.

[PonteIneptique]

I'd say we change https://distributed-text-services.github.io/specifications/Entry.html#base-api-endpoint to specify something like this ? Maybe methods ?

[monotasker]

I think the Hydra spec provides a way for clients to discover automatically which endpoints and methods are available, doesn't it?

[PonteIneptique]

Not only that but on top of this, if this is about methods (we already have GET), a good OPTIONS query should get what we want right ? Le jeu. 24 janv. 2019 à 17:50, Ian W. Scott <notifications@github.com> a écrit :

…

I think the Hydra spec provides a way for clients to discover automatically which endpoints and methods are available, doesn't it? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB1yZm_IPlVuioD6Oe9wIECqtvOc9n3Eks5vGeRKgaJpZM4aRBpq> .

[jonathanrobie]

I think the Hydra spec provides a way for clients to discover automatically which endpoints and methods are available, doesn't it?

Yes, that's probably the right approach. We should say that this metadata should be provided if these methods are supported for an endpoint.

a good OPTIONS query should get what we want right ?

Well, yes, but ...

Few clients actually do an OPTIONS query, they are more likely to try it and see if it works. And doing an additional request to see what is available is much less convenient than reading the metadata to see.