specs

specs copied to clipboard

This is a first step towards #84: instead of leaving the suggest, preview and property proposal paths up to the implementer, those paths are pre-determined by the spec.

This was also the occasion to remove the flyout: I had to do this when changing the manifest structure. Sorry to be bundling that up in the same PR, I should have done another one about this earlier. Therefore it closes #42.

It also closes #32 in the same go.

Thanks, good catch!

For GET vs POST, I guess we are still limited by the fact that:

• passing GET parameters in the URL is subject to length limits
• passing GET parameters in the body is a pretty uncommon / weird thing to do, which might require contortions depending on the framework used for the server or client

But I get that it might also be weird to use POST in some web frameworks, typically those which enforce some sort of CSRF protection on such endpoints (which would need to be disabled for our purposes).

I'd prefer that we stay with HTTP POST as we have defined in the latest draft.

This would allow a bit more flexibility in the kinds of entities that could potentially be reconciled. For instance, I wonder if it should be optional for a service to use multipart/form-data for binary data and not only application/x-www-form-urlencoded but haven't thought about it much beyond use cases of machine learning with file data such as images or sound clips with associated metadata.

BTW there seems to be an upcoming new verb for 'GET with a body', currently called SEARCH.

By now it's called QUERY method. I think this is the most up-to-date draft: https://www.rfc-editor.org/rfc/internet-drafts/draft-ietf-httpbis-safe-method-w-body-03.html (See also this post for some background: https://evertpot.com/get-request-bodies/)

This would allow a bit more flexibility in the kinds of entities that could potentially be reconciled. For instance, I wonder if it should be optional for a service to use multipart/form-data for binary data and not only application/x-www-form-urlencoded but haven't thought about it much beyond use cases of machine learning with file data such as images or sound clips with associated metadata.

Actually we want to migrate out of such content-types because they are not as REST-friendly as just application/json.