Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 365534

Summary:	[server] GET Git Log isn't RESTy
Product:	[ECD] Orion	Reporter:	Tomasz Zarna <tomasz.zarna>
Component:	Git	Assignee:	Project Inbox <orion.git-inbox>
Status:	RESOLVED WONTFIX	QA Contact:
Severity:	normal
Priority:	P3	CC:	simon_kaegi
Version:	0.3
Target Milestone:	---
Hardware:	PC
OS:	Windows XP
Whiteboard:

Description Tomasz Zarna

2011-12-04 18:41:05 EST

GET requests should be safe and idempotent. This isn't true for long running Git Log ops. As the result of bug 358079 the response can either be 200, if you're lucky or 202, if the server needs more time to process your request. In case of the latter a task is created, which should not happen for GET requests.

A solution, that came first to my mind, is to return immediately for GETs, but for long running ops inform the client that he needs to send a subsequent POST request to start a task (the URL could be in the response). This is an extra round-trip, but I guess this is the price for being RESTful..

Comment 1 Szymon Brandys

2011-12-12 07:53:44 EST

Gosia, I think this is another subitem for your progress service work.

Comment 2 Malgorzata Janczarska

2011-12-12 09:01:54 EST

I don't think that creating the task is a problem as long as it's not persisted on the server. This is normal that when handling every GET we start some operations and they exist on the server until they are not finished. Than their outcome is send to the server. If we got a timeout the operations wouldn't be probably canceled and we could say they still exist on the server until they finish.

I think our problem is that we persist those operations. This is not REST-y.
I think this is some kind connected to Bug 366062. The problematic tasks the here are I think mostly GETs. We also don't need them to be persisted.

Comment 3 Simon Kaegi

2015-05-08 12:23:56 EDT