[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (OSLCCORE-9) Bootstrapping discovery
[ https://issues.oasis-open.org/browse/OSLCCORE-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=59594#comment-59594 ]
Martin Pain commented on OSLCCORE-9:
-------------------------------------
A few scenarios:
1) The user uses a webapp at http://myserver.example.com/. They are used to using the web UI. They want to start using a client with this server, which happens to use OSLC (and the server's compatible). They enter that URL in the client. The client does a GET asking for text/turtle, and gets the 'root' LDPC, from which it can discover all other capabilities on the server.
2) A webapp container (e.g. Tomcat) is running multiple webapps from different vendors. They are all on the same port, at different context roots. One such app is at https://example.com/myserver/. The user is used to using that as their starting point for the web UI. They enter that into the OSLC client. However, the server exposes its root LDPC at https://example.com/myserver/rootservices.ttl (either because a text/turtle response from /myserver/ already returns something else, or they don't like or don't know about client-driven content-negotiation, or they want to keep their HTML UI URLs and REST API URLs cleanly separate, or it's provided by a plug-in and the plug-in architecture doesn't allow for adding content negotiation on existing URLs). Either the user needs to search the server's docs to find the right URL to provide to the client (which is a horrible user experience in my opinion - or at least one that can be vastly improved) or the client needs to be able to find the root LDPC based on the URL that the user gave them.
3) The user usually enters a webapp on a page other than the home page, e.g. https://example.com/myserver/projects/myproject/dashboard?layout=2. That is the entry point they use so, not thinking about it, that's the URL they paste into the client. Content-negotiation on that URL to get the 'root' LDPC wouldn't make sense, but the client ideally should still be ble to find the root LDPC from that URL. Going to the root path wouldn't work, as this app doesn't have control out of anything outside "/myserver/".
I suggested a Link header to cover cases like these, so discovery can be bootstrapped from any URL in the web app (if the server exposes the Link header on all its pages, which I would suggest we consider making a SHOULD). This doesn't solve all these problems, but gives them more flexibility than forcing content-negotiation or a well-known URL (such as "/"). See my email https://lists.oasis-open.org/archives/oslc-core/201503/msg00016.html.
I still haven't read mnot's "Home documents for HTTP APIs" draft to see if that suggests a solution to the discovery bootstrapping problem.
> Bootstrapping discovery
> -----------------------
>
> Key: OSLCCORE-9
> URL: https://issues.oasis-open.org/browse/OSLCCORE-9
> Project: OASIS OSLC Lifecycle Integration Core (OSLC Core) TC
> Issue Type: Task
> Reporter: Martin Pain
> Assignee: James Amsden
>
> See https://lists.oasis-open.org/archives/oslc-core/201503/msg00016.html
> See also a draft from Mark Nottingham about HTTP home documents: http://tools.ietf.org/html/draft-nottingham-json-home-03 (I haven't read it yet)
--
This message was sent by Atlassian JIRA
(v6.2.2#6258)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]