Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make explicit what HTTP Verbs are to be supported by an XProc 3.0 processor #42

Open
fsasaki opened this issue Feb 9, 2019 · 5 comments

Comments

Projects
None yet
3 participants
@fsasaki
Copy link

commented Feb 9, 2019

The current draft of the "steps" specification says:
"The method attribute specifies the method to be used against the IRI specified by the href attribute, e.g. GET or POST (the value is not case-sensitive). If the href attribute is not absolute, it will be resolved against the base URI of the element on which it is occurs."
Two comments on that

  1. It should be made explizit what HTTP Verbs are to be processed by an XProc 3.0 processor
  2. The following verbs should be mandatory for a processor: GET, POST, PUT, DELETE, HEAD .
    Rationale: for using XProc in a micro-services environment, having HTTP verbs available would allow to create an "XProc only" workflow, without the need to use a different (non XML) technologies just for the service communication layer.
@fsasaki

This comment has been minimized.

Copy link
Author

commented Feb 9, 2019

The version of the spec I commented on is build 750, see xproc/3.0-specification@8e7aade

@xml-project xml-project transferred this issue from xproc/3.0-specification Feb 10, 2019

@eriksiegel eriksiegel changed the title Make explizit what HTTP Verbs are to be supported by an XProc 3.0 processor Make explicit what HTTP Verbs are to be supported by an XProc 3.0 processor Jun 10, 2019

@ndw

This comment has been minimized.

Copy link
Collaborator

commented Jun 10, 2019

We'll update the spec to say that implementations are required to document the verbs that they implement and that they SHOULD implement GET, POST, PUT, DELETE, and HEAD (for HTTP).

@Conal-Tuohy

This comment has been minimized.

Copy link

commented Jun 13, 2019

I am wary about explicitly listing the verbs that SHOULD be supported, because I think it would send a message to XProc implementors that they need a "white-list" of HTTP methods (and that verbs outside of that list should be rejected). But in fact http-request doesn't need a white-list of HTTP methods, any more than it needs a white-list of supported HTTP headers. The set of HTTP verbs is arbitrarily extensible, and p:http-request only needs to make the HTTP request as specified by the c:request document; the HTTP verb specified there is just a token in the HTTP message, which the http-request step only needs to pass on to the HTTP server to interpret. Of course if p:http-request recognises a verb it may merit some special treatment (such as e.g. caching of GET requests), but if the verb is unknown then that's no reason for rejecting it. As someone who has had to use PATCH for dealing with a metadata repository, and had to ahem patch XMLCalabash to add support, I think explicitly enumerating the verbs which SHOULD be "supported" might have the practical effect of unnecessarily limiting support for the less common HTTP verbs (such as OPTIONS and PATCH and the zillion other verbs used in WebDAV) and any new or custom verbs.

My suggestion is that the spec should say that the p:http-request step should support any and all HTTP request methods.

@fsasaki

This comment has been minimized.

Copy link
Author

commented Jun 16, 2019

I am fine by the resolution proposed at #42 (comment) - thanks, Norm.

@Conal-Tuohy

This comment has been minimized.

Copy link

commented Jun 19, 2019

The PATCH method is another one which does get some use. I have used it myself (in XProc) last year with the web API of Symplectics Elements (a metadata repository), and I've also used it (not in XProc) with Fedora Repository, which implements the Linked Data Platform, in which PATCH support is mandatory. It's also part of the SPARQL Graph Store Protocol. If there's to be a list of methods (which I still think is a mistaken idea), then I would really like PATCH to be on it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.