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

Determine when re-write of RDFSource request/response bodies are required, and implement #15

Open
birkland opened this issue May 13, 2016 · 3 comments

Comments

@birkland
Copy link
Contributor

As API-X provides a proxy endpoint for Fedora, repository resources exposed through API-X have different URIs than their fedora counterparts.  When relative URIs are used in requests and response, there is no issue.  Absolute URIs may need to be rewritten in request and response bodies.  This is akin to mod_proxy_html, except for rdf.

Testing:  

  • PATCH, POST, PUT, GET in supported media types (turtle, n-triples, sparql update) where absolute URIs are present
    • Measure latency/throughput impact of doing this
@acoburn
Copy link
Contributor

acoburn commented May 13, 2016

This W3C document is relevant to this discussion: https://www.w3.org/TR/ct-guidelines/

@ajs6f
Copy link
Contributor

ajs6f commented May 14, 2016

We could use that for fcrepo-transform. Or maybe fcrepo-transform should factor into API-X, actually. Okay, different issue.

@birkland
Copy link
Contributor Author

@acoburn Yes, though I'm thinking that many (most?) scenarios will resemble what RFC3040 describes as a 'surrogate'. In particular

surrogate
A gateway co-located with an origin server, or at a different
point in the network, delegated the authority to operate on behalf
of, and typically working in close co-operation with, one or more
origin servers.
...
Where close co-operation between origin servers and surrogates
exists, this enables modifications of some protocol requirements,
including the Cache-Control directives in [1]. Such modifications
have yet to be fully specified.

We should also look at contemporary implementations of API gateways to see what best practices are in this regard.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants