Role Assignment Discovery Issue for Files and Folders through Sharepoint REST services

Question

To preface, I am a decided Sharepoint newbie in every sense. I am trying to use the Sharepoint REST services (Sharepoint 2013) to walk the folder and file structure of my Sharepoint server and, determine as I go, the Role Assignments (and subsequently
Permissions) on those folders and files. I'm using an Administrator credentials and I'm actually able to successfully do it but I've run into some caveats. All the caveats begin with this; when I'm examining a folder, for example:
/_api/Web/GetFolderByServerRelativeUrl('/sites/cmisdev/Development')/ListItemAllFields
I receive either an empty list or an error response doc when following the link supplied for ListItemAllFields.  When following that kind of link for folders, I either get:
<d:ListItemAllFields
m:null="true"
/>
or an error response document that says "The object specified does not belong to a list." When I hit the /ListItemAllFields endpoint for files, I receive a response with a link for Role Assignments which subsequently also works and I get the
info I need. So, is this a bug? Why does the link returned from Sharepoint work for files and not folders? So, google, google, google, and I discover that there is another possible way to get at the Role Assignments (and that the object does, indeed, belong
to a list!).
If I know the Title (or the guid) of the folder in question, I can use the following endpoint:
/_api/Web/Lists/GetByTitle('Development')
If I use that endpoint, I get the information I would have expected to get from following /ListItemAllFields and the subsequent Role Assignments links all work and I get what I need. If there's a bug and this is how I have to work around it, that's fine
but I have yet to discover how to dynamically determine the Title of a given folder nor am I sure if all Titles are supposed to be unique within a given Sharepoint server. I'm assuming that the folder name as represented in the server relative URL and the
Title may be different and this is where my newbishness may start to shine if I'm misunderstanding what a "List" is supposed to be in Sharepoint. Anyway, I did find that I could use the Properties endpoint to perhaps get the Title, for example:
/_api/Web/GetFolderByServerRelativeUrl('/sites/cmisdev/Development')/Properties
gives me:
<d:vti_x005f_listtitle>Development</d:vti_x005f_listtitle>
whose value I assume I could then supply to the /GetByTitle endpoint and be golden. However, "vti_x005f_listtitle" just sounds a little too deep to be something I should be relying on but maybe that's kosher. That's part of what I'm trying to
find out. Also, if there is a way to use the Sharepoint REST API to discover the guid of a given object, then I could look it up in that way.
So, in summary:
1. Am I going about getting folder Role Assignment information in the wrong way? Based on the CSOM examples I've seen, I believe I'm doing it correctly and that the answer to #2 below is a resounding "Yes!" :)
2. Is it a bug if I'm not able to use /ListItemAllFields on folders using the server relative url?
3. If I'm supposed to use GetByTitle as a workaround, am I discovering that Title correctly through /Properties? Seems quite circuitous and awkward. Are Titles required to be unique throughout a given Sharepoint server?
4. If I'm supposed to use the guid, how can I use the REST interface to discover an object's guid? Once we get down to the Role Assignments and other links, the guid appears in those links but I don't know how to discover it independently if that's the
path I should use to get the data I described above.

Answer 1

Upon further research, I'll answer my own question for the benefit of some other potential future newbie.  The answer to question number 1 above is "Not exactly.".  The server relative URLs I was using corresponded to lists (which are
returned as a collection through /_api/web/lists).  I was treating them mentally like regular folders.  That, coupled with the fact that accessing their data as I showed above returns a ListItemAllFields link, made me think that was the way to get
the Role Assignments just as I would for files and, as it turns out, "real" folders and sub-folders created under these lists.  That was the other problem with thinking of these lists as regular folders.  So, ListItemAllFields works on
all files and folders in a list.  However, if you want Role Assignments for the lists themselves, you can keep track of the Titles and\or Guids from the /_api/web/lists that you're interested in (in my case, all non-hidden "document library"
type lists) and then access those Role Assignments as I discussed in questions 3 and 4 above.  For example, from the /_api/web/lists collection from my test server, the "Development" document library Role Assignments are accessable via /_api/Web/Lists(guid'cd242eeb-aafa-4efa-aecc-9bbdf8e3d459')/RoleAssignments
or /_api/Web/Lists/GetByTitle('Development')/RoleAssignments.