DAP4: Capabilities and Versioning - Revision history

Jimg: /* Discussion */

2012-05-10T20:48:45Z

Discussion

← Older revision		Revision as of 20:48, 10 May 2012
Line 235:		Line 235:
	== Discussion ==		== Discussion ==

	~~----~~		[[User:Jimg\|Jimg]] 13:48, 10 May 2012 (PDT) I would like to see this broken up into two or more papers where one specifies the proposed HTTP implementation of the requests and responses of DAP4. Others can specify the structure and interpretation of the Capabilities response and how a web service will support multiple versions of DAP, including DAP2 and DAP4 (and variants of those protocols, should we allow that).




	== Examples ==		== Examples ==

EthanDavis: /* Rationale for the solution */

2012-04-25T22:51:13Z

Rationale for the solution

← Older revision		Revision as of 22:51, 25 April 2012
Line 215:		Line 215:
	The bottom line is that features of the chosen transport protocol should be used by web applications to the fullest extent possible to gain the advantages of the features of that transport protocol. A relevant quote from Wikipedia's REST page [2]:		The bottom line is that features of the chosen transport protocol should be used by web applications to the fullest extent possible to gain the advantages of the features of that transport protocol. A relevant quote from Wikipedia's REST page [2]:

			<blockquote>
	RESTful applications maximize the use of the pre-existing,		RESTful applications maximize the use of the pre-existing,
	well-defined interface and other built-in capabilities provided by		well-defined interface and other built-in capabilities provided by
	the chosen network protocol, and minimize the addition of new		the chosen network protocol, and minimize the addition of new
	application-specific features on top of it.		application-specific features on top of it.
			</blockquote>

	and another one specific to HTTP [2]:		and another one specific to HTTP [2]:

			<blockquote>
	HTTP, for example, has a very rich vocabulary in terms of verbs		HTTP, for example, has a very rich vocabulary in terms of verbs
	(or "methods"), URIs, Internet media types, request and response		(or "methods"), URIs, Internet media types, request and response
Line 228:		Line 231:
	components to perform additional functions on the network such as		components to perform additional functions on the network such as
	HTTP caching and security enforcement.		HTTP caching and security enforcement.
			</blockquote>

	== Discussion ==		== Discussion ==

EthanDavis: /* Rationale for the solution */

2012-04-25T22:50:11Z

Rationale for the solution

← Older revision		Revision as of 22:50, 25 April 2012
Line 204:		Line 204:
	(encoding formats), specifications have a natural division into		(encoding formats), specifications have a natural division into
	separate components.		separate components.
	- The specification of a link/resource type defines the set of		* The specification of a link/resource type defines the set of information and links allowed in a resources of that type.
	information and links allowed in a resources of that type.		* The specification of a media type defines how the information and links allowed in the targetted resource type are encoded.
	- The specification of a media type defines how the information and		* The specification of how the network application is bound to a specific transport protocol (like HTTP).
	links allowed in the targetted resource type are encoded.
	- The specification of how the network application is bound to a
	specific transport protocol (like HTTP).

	To take advantage of the caching built into the web		To take advantage of the caching built into the web

EthanDavis: /* Some References */

2012-04-25T22:48:56Z

Some References

← Older revision		Revision as of 22:48, 25 April 2012
Line 379:		Line 379:
	[1] http://stackoverflow.com/a/385216		[1] http://stackoverflow.com/a/385216
	* A stackoverflow answer to the question "Use 'Accept' header or extension to identify resource type?" Answer: the ideal would be to implement both.		* A stackoverflow answer to the question "Use 'Accept' header or extension to identify resource type?" Answer: the ideal would be to implement both.

	[2] http://en.wikipedia.org/wiki/Representational_state_transfer		[2] http://en.wikipedia.org/wiki/Representational_state_transfer

	[3] http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm		[3] http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

EthanDavis: /* Some References */

2012-04-25T22:48:39Z

Some References

← Older revision		Revision as of 22:48, 25 April 2012
Line 377:		Line 377:
	== Some References ==		== Some References ==

	* http://stackoverflow.com/a/385216		[1] http://stackoverflow.com/a/385216
	** Response to the question: Use "Accept" header or extension to identify resource type?		* A stackoverflow answer to the question "Use 'Accept' header or extension to identify resource type?" Answer: the ideal would be to implement both.
	** The ideal would be to implement both.		[2] http://en.wikipedia.org/wiki/Representational_state_transfer
			[3] http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

EthanDavis: /* Rationale for the solution */

2012-04-25T22:46:22Z

Rationale for the solution

← Older revision		Revision as of 22:46, 25 April 2012
Line 195:		Line 195:
	== Rationale for the solution ==		== Rationale for the solution ==

	In an attempt to take advantage of the architecture of the web, this proposal is based on some RESTful ideas. ~~First off,~~ REST targets networks of hypermedia resources connected to each other by the hyperlinks those resources contain. The links in the network can have link types that specify the type of resource that will be found at the end of the link. Link types define the set of information and the links that can be contained by a resource of that type. Each resource type can have multiple encodings in which a resource of that type can be represented.		In an attempt to take advantage of the architecture of the web, this proposal is based on some RESTful ideas. REST targets networks of hypermedia resources connected to each other by the hyperlinks those resources contain. The links in the network can have link types that specify the type of resource that will be found at the end of the link. Link types define the set of information and the links that can be contained by a resource of that type. Each resource type can have multiple encodings in which a resource of that type can be represented.

	This architecture ~~makes~~ for a robust and extensible system. URLs can change and new links can be added without breaking the system. The links in a resource provide an application the set of next available steps the application can take. Or another way of thinking about it, the network of hypermedia resources represent a virtual state machine for the web application. Moving the description of the web application into the network of resources removes some of the tight coupling often seen between client and server. The form of the URLs becomes an implementation detail, determined by the server, rather than a part of the specification.		This architecture can make for a robust and extensible system. URLs can change and new links can be added without breaking the system. The links in a resource provide an application the set of next available steps the application can take. Or another way of thinking about it, the network of hypermedia resources represent a virtual state machine for the web application.

			By specifying all URLs in links rather than defining them in a specification, the form of the URLs becomes an implementation detail, determined by the server, rather than a part of the specification. This helps remove some of the tight coupling often seen between client and server. (This does not, however, rule out the use of URL conventions, like file extensions to specify encoding forms. Some recommend support for both HTTP '''Accept''' headers and for file extensions [1].)

			By thinking in terms of link (resource) types and media types
			(encoding formats), specifications have a natural division into
			separate components.
			- The specification of a link/resource type defines the set of
			information and links allowed in a resources of that type.
			- The specification of a media type defines how the information and
			links allowed in the targetted resource type are encoded.
			- The specification of how the network application is bound to a
			specific transport protocol (like HTTP).

			To take advantage of the caching built into the web
			infrastructure, one should think about commonly used resources and
			whether they can be made somewhat stable and quick to return. Or at
			least be sure HTTP caching headers are used properly.

	~~http~~:~~//www.ics.uci.edu/~fielding/pubs/dissertation/top.htm~~		The bottom line is that features of the chosen transport protocol should be used by web applications to the fullest extent possible to gain the advantages of the features of that transport protocol. A relevant quote from Wikipedia's REST page [2]:

	* Allows servers full control of ~~their URL space~~		RESTful applications maximize the use of the pre-existing,
	** DAP4 URLs are identified by ~~their link type rather than~~ a ~~hard wired~~ "~~file extension~~".		well-defined interface and other built-in capabilities provided by
	** On the ~~other hand, file extensions can also be supported~~.		the chosen network protocol, and minimize the addition of new
			application-specific features on top of it.

			and another one specific to HTTP [2]:

			HTTP, for example, has a very rich vocabulary in terms of verbs
			(or "methods"), URIs, Internet media types, request and response
			codes, etc. REST uses these existing features of the HTTP
			protocol, and thus allows existing layered proxy and gateway
			components to perform additional functions on the network such as
			HTTP caching and security enforcement.

	== Discussion ==		== Discussion ==

EthanDavis: /* Rationale for the solution */

2012-04-25T20:49:02Z

Rationale for the solution

← Older revision		Revision as of 20:49, 25 April 2012
Line 197:		Line 197:
	In an attempt to take advantage of the architecture of the web, this proposal is based on some RESTful ideas. First off, REST targets networks of hypermedia resources connected to each other by the hyperlinks those resources contain. The links in the network can have link types that specify the type of resource that will be found at the end of the link. Link types define the set of information and the links that can be contained by a resource of that type. Each resource type can have multiple encodings in which a resource of that type can be represented.		In an attempt to take advantage of the architecture of the web, this proposal is based on some RESTful ideas. First off, REST targets networks of hypermedia resources connected to each other by the hyperlinks those resources contain. The links in the network can have link types that specify the type of resource that will be found at the end of the link. Link types define the set of information and the links that can be contained by a resource of that type. Each resource type can have multiple encodings in which a resource of that type can be represented.

	This architecture makes for a robust and extensible system. URLs can change and new links can be added without breaking the system. ~~Each resource in the network (through the~~ links ~~contained~~ in ~~that~~ resource~~) presents~~ the ~~application its~~ next available steps. ~~(Thus removing~~ some of the tight coupling often seen between client and server. The form of the URLs becomes an implementation detail, determined by the server, rather than a part of the specification.)		This architecture makes for a robust and extensible system. URLs can change and new links can be added without breaking the system. The links in a resource provide an application the set of next available steps the application can take. Or another way of thinking about it, the network of hypermedia resources represent a virtual state machine for the web application. Moving the description of the web application into the network of resources removes some of the tight coupling often seen between client and server. The form of the URLs becomes an implementation detail, determined by the server, rather than a part of the specification.




			http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

	* Allows servers full control of their URL space		* Allows servers full control of their URL space

EthanDavis: /* Rationale for the solution */

2012-04-25T20:29:31Z

Rationale for the solution

← Older revision		Revision as of 20:29, 25 April 2012
Line 194:		Line 194:

	== Rationale for the solution ==		== Rationale for the solution ==

			In an attempt to take advantage of the architecture of the web, this proposal is based on some RESTful ideas. First off, REST targets networks of hypermedia resources connected to each other by the hyperlinks those resources contain. The links in the network can have link types that specify the type of resource that will be found at the end of the link. Link types define the set of information and the links that can be contained by a resource of that type. Each resource type can have multiple encodings in which a resource of that type can be represented.

			This architecture makes for a robust and extensible system. URLs can change and new links can be added without breaking the system. Each resource in the network (through the links contained in that resource) presents the application its next available steps. (Thus removing some of the tight coupling often seen between client and server. The form of the URLs becomes an implementation detail, determined by the server, rather than a part of the specification.)




	* Allows servers full control of their URL space		* Allows servers full control of their URL space

EthanDavis: /* Server Capabilities Document Request-Response */

2012-04-24T23:19:45Z

Server Capabilities Document Request-Response

← Older revision		Revision as of 23:19, 24 April 2012
Line 255:		Line 255:
	href="http://server/dap/path/data.nc.ddx"/>		href="http://server/dap/path/data.nc.ddx"/>
	<serviceLink rel="http://opendap.org/rel/dap2/dods"		<serviceLink rel="http://opendap.org/rel/dap2/dods"
	type="application/vnd.opendap.org.dap2.dods,		type="application/vnd.opendap.org.dap2.dods"
	~~application/vnd.opendap.org.dap2.dods+ascii~~"
	href="http://server/dap/path/data.nc.dods"/>		href="http://server/dap/path/data.nc.dods"/>
			<serviceLink rel="http://opendap.org/rel/dap2/dods"
			type="application/vnd.opendap.org.dap2.dods+ascii"
			href="http://server/dap/path/data.nc.ascii"/>
	<constraintExp ...>...</constraintExp>		<constraintExp ...>...</constraintExp>
	<processing ...>...</processing>		<processing ...>...</processing>

EthanDavis at 18:28, 24 April 2012

2012-04-24T18:28:46Z

← Older revision		Revision as of 18:28, 24 April 2012
Line 133:		Line 133:

	Do we need/want a server-level capabilities document? Or is a dataset-level one enough?		Do we need/want a server-level capabilities document? Or is a dataset-level one enough?


			Server capabilities documents are encoded in the same media types that are defined for the DAP4 Dataset Capabilities Documents (see [[#DAP4 Dataset Capabilities Documents\|above]]).

			A link to a Server Capabilities document can be identified by the following link relationship type:

			* '''<nowiki>http://opendap.org/rel/dap/server</nowiki>'''

			The URL of a link with this relation type can be used to GET the server capabilities document for the server.

	=== DAP2 DAS ===		=== DAP2 DAS ===