API Roadmap - Revision history

Joar at 11:44, 7 March 2012

2012-03-07T11:44:34Z

← Older revision		Revision as of 11:44, 7 March 2012
Line 32:		Line 32:

	[[REST_API]] might contain some usable input on this.		[[REST_API]] might contain some usable input on this.
	== Implementation of some kind of API ==


	== Investigating already existing protocols ==		== Investigating already existing protocols ==

2012-03-07T11:43:44Z

Roadmap

@@ Line 1: / Line 1: @@
 = Roadmap =
 # [[API_Roadmap#Investigating_already_existing_protocols]]
 # Implement the REST API
@@ Line 23: / Line 23: @@
 #** Callback
 #** Resource
 == Investigating already existing protocols ==

2012-03-07T11:27:35Z

2012-02-18: Hacking session

← Older revision		Revision as of 11:27, 7 March 2012
Line 42:		Line 42:
	Try to determine what kind of authentication we could provide for the descibed scenario.		Try to determine what kind of authentication we could provide for the descibed scenario.

	<del>According to http://webreflection.blogspot.com/2008/06/ajax-or-javascript-subdomain-requestes.html it is possible to access a subdomain from another parent domain/subdomain sharing the same parent domain.</del> not ~~feasible~~.		<del>According to http://webreflection.blogspot.com/2008/06/ajax-or-javascript-subdomain-requestes.html it is possible to access a subdomain from another parent domain/subdomain sharing the same parent domain.</del> This did not seem like a good idea after all. It has been decided to use [http://en.wikipedia.org/wiki/Cross-origin_resource_sharing CORS] for cross-domain requests.

	==== Results ====		==== Results ====

2012-03-07T11:25:12Z

@@ Line 1: / Line 1: @@
 == Sessions ==
 === 2012-02-18: Hacking session ===
@@ Line 37: / Line 75: @@
 * OAuth code examples - http://oauth.net/code/
 * [[REST API]]
@@ Line 104: / Line 118: @@
 /12:24.59 < joar> tryggvib: Can I write this down in the wiki?
 </pre>

2012-03-07T11:13:27Z

Evaluating old wheels

← Older revision		Revision as of 11:13, 7 March 2012
Line 104:		Line 104:
	13/12:24.59 < joar> tryggvib: Can I write this down in the wiki?		13/12:24.59 < joar> tryggvib: Can I write this down in the wiki?
	</pre>		</pre>

			== Investigating already existing protocols ==
			Before reinventing the wheel, we should analyze existing wheels. That means, existing protocols should be evaluated, whether they fit the needs. Of course only a certain subset of "old wheels" can be looked at, but the most important ones shouldn't be left out.
			Using an existing protocol could also save work. At least on the client side, because the clients usualy already exist. Existing clients could also greatly help in developing the server side (easy testing!).
			The results of this evaluation should be documented so that there is an easy place to point people at who ask "Why didn't you use Y for your main protocol, it's great!".

			Protocols that come to mind, and should possibly be evaluated:
			* [http://www.flickr.com/services/api/ flickr api]
			* gallery2 api
			* …

			Of course any of those "old wheels" can later be implemented as a plugin and be enabled by users.

2012-02-26T00:52:42Z

← Older revision		Revision as of 00:52, 26 February 2012
Line 49:		Line 49:
	#** <code>/u/{user}/gallery/</code>		#** <code>/u/{user}/gallery/</code>
	#*** Offer alternative output format		#*** Offer alternative output format
			# Add webhook callback to Processing
	#* Testing
	# CORS		# CORS
	#* CORS-enable views		#* CORS-enable views
	#** <code>CORSEnabled</code> wrapper for views		#** <code>CORSEnabled</code> wrapper for views
	# OAuth		# OAuth
	#* ~~Provide~~ OAuth ~~authentication~~		#* OAuth research
			#* OAuth views[https://github.com/simplegeo/python-oauth2/blob/master/example/server.py]
			#** Request
			#** Access
			#** Authorization
			#** Callback
			#** Resource

2012-02-25T18:58:27Z

← Older revision		Revision as of 18:58, 25 February 2012
Line 42:		Line 42:
	# Implement the REST API		# Implement the REST API
	#* Views		#* Views
			#** <code>/submit/</code>
	#* Functionality
			#*** Accept webhook argument
			#*** Offer alternative output format
			#** <code>/u/{user}/m/{media}</code>
			#*** Offer alternative output format
			#** <code>/u/{user}/gallery/</code>
			#*** Offer alternative output format
	#* Testing		#* Testing
	# CORS		# CORS
	#* CORS-~~enabled~~ views		#* CORS-enable views
			#** <code>CORSEnabled</code> wrapper for views
	# OAuth		# OAuth
	#* OAuth ~~provider~~		#* Provide OAuth authentication

2012-02-22T12:36:49Z

Tasks

← Older revision		Revision as of 12:36, 22 February 2012
Line 41:		Line 41:
	# Specify details of the REST API		# Specify details of the REST API
	# Implement the REST API		# Implement the REST API
			#* Views
			#* Functionality
			#* Testing
	# CORS		# CORS
	#*CORS-~~implementation~~		#* CORS-enabled views
	# OAuth		# OAuth
	#* ~~Set up~~ OAuth provider		#* OAuth provider
	#*

2012-02-20T17:20:08Z

← Older revision		Revision as of 17:20, 20 February 2012
Line 39:		Line 39:

	== Tasks ==		== Tasks ==
	# ~~Define~~ ~~structure~~ of REST API		# Specify details of the REST API
	# Implement the REST API		# Implement the REST API
	# ~~Implement~~ CORS		# CORS
			#*CORS-implementation
	# ~~Implement~~ OAuth		# OAuth
			#* Set up OAuth provider
			#*


	=== IRC source ===		=== IRC source ===

2012-02-18T18:49:54Z

Results

← Older revision		Revision as of 18:49, 18 February 2012
Line 7:		Line 7:

	==== Results ====		==== Results ====
	~~Use~~ [http://en.wikipedia.org/wiki/Cross-origin_resource_sharing CORS] to enable cross-domain AJAX ~~request since all existing cross-domain hacks use an iframe~~.		* [http://en.wikipedia.org/wiki/Cross-origin_resource_sharing CORS] to enable cross-domain AJAX requests.
			* OAuth for authentication

	Authentication will be supported by OAuth.

	== Network layout ==		== Network layout ==