API method to get a list of all [depot] filenames in a diff

Review Request #1199 — Created Nov. 8, 2009 and discarded

Information

pv
Review Board
master

Reviewers

mak
Review 1013 (http://reviews.reviewboard.org/r/1013/) is useful to me, but I am trying to get a list of all of [latest] filenames in a review request.
This change extends Mak's (1013) change to allow me to do that.

This solution requires two JSON calls for me to get a list of filenames.
1) http://server/reviewrequests/%d/diff/
2) http://server/diff/%d/filenames/

In all honesty, I don't actually like needing to make two JSON calls when I could implement what I need in one JSON call.

So, Option #2, I would much prefer the a single request such as:
http://server/reviewrequests/%d/filenames/
(This always gets the filenames from the latest diff revision)

Option #3, another alternative, would be to get a list of filenames directly from a reviewrequest's diff revisions:
http://server/reviewrequests/%d/diff/latest/filenames/ 
http://server/reviewrequests/%d/diff/%d/filenames/ 


Option #3 is kindof slick, but I prefer Option #2, since this doesn't obligate me to complicate the API with a "latest" revision alias.



Finally, would Mak be OK w/ me changing his API from "/diff/" to "/diffs/"?
Change is still open to debate, so no test(s) added yet.
PV
Review request changed
chipx86
  1. I'm unsure of how this maps to option #2. You still need to know the diffset ID. You just don't need the review request ID. However, we can't accept a change that puts a /api/json/diffs/... tree. Anything diff-related should be in reviewrequests/<id>/diff/ somewhere.
    
    What I'd be okay with is adding reviewrequests/<id>/diff/<diffsetid>/ and reviewrequests/<id>/diff/latest/. It should return the filediffs inside of it, though, not just filenames.
    1. The change was mostly just a proposal/RFC and only implemented option #1.
      #2 would have been a nice lightweight solution just for my needs.
      Sounds like you'd be OK w/ #3, which I will code up Monday. The solution will return the whole filediffs, not just the names.
      (I am OK w/ parsing the filediffs on the caller and extracting the depot_filenames; simple list comprehension).
      
      Understood about not wanting a root "diffs" api.
      That said, why not alias all diffs in the API w/ a '[s]?', as in:
        r'reviewrequests/(?P<review_request_id>[0-9]+)/diff[s]?/(?P<diff_revision>[0-9]+)/'
      '.../diffs/42/...' makes more logical sense than '.../diff/42/...'
      
    2. Maybe at some point. There's actually a lot I want to do with the API, some of which may be backwards-incompatible, but I'm trying to limit things right now. Might explore this for 1.2.
    3. Sorry, I didn't see this earlier. But I don't use the Account "mak" anymore (Christian: Can you please change the user under "People"?).
      To the request: #2 looks good to me. Even though I probably won't use it (I just extract the filenames from the diff).
  2. 
      
chipx86
  1. The new API in 1.5 beta 2 has all this information now.
  2.