When using the Entity API, is it fairly simple to interact with Taxonomy, Path/Pathauto, XML Sitemap, and Views? If so, what parts of the API should I be looking at?
Your question is a little confusing because Entity API is actually a separate contributed module that works with the core entity/fields api's
I've been working with the core
EntityFieldQuery class and have been using it to query nodes (and other entities), their fields and properties with great success. You can checkout another question that's building some examples at:
What's the proper use of EntityFieldQuery?
Overally, I found the Entity API was very handy for creating my own entities but didn't find the documentation all that great for doing queries on my site's content.
note, that node/user are now entities & node types/etc are now considered "bundles".
In response to the original question and to electblake's answer, I would second the fact that the Entity API contributed module is separate and distinct from the core entity system. It is meant to augment the core system by providing a more robust entity controller (the piece of code used to create, load, save, and delete entities), provide some automatic token generation, and allow modules to define metadata for their entities' properties.
electblake mentioned that the core entity system includes a class for querying entities in the database based on their property and field data called EntityFieldQuery. This is in fact the recommended way for making entity queries. The Entity API isn't actually meant to be a querying tool. However, it provides in my opinion the other missing piece for building robust contributed modules using entities and fields - the entity metadata wrapper.
As I mentioned, the Entity API module provides a hook that lets you define metadata for your entity's properties (i.e. $node->uid, $node->created). It combines this information with what it knows about field definitions and instances. It then lets you "wrap" an entity to make it easier to access and manipulate field data and (what I'll call) referenced entity data through the wrapper object. One of the main things this has made easier for me is not having to worry about the language of entities when I'm trying to access their field data. Without the wrapper, you need to know the schema array of the data you're trying to access or manipulate. Using it, you can simply access field data like any other property.
Additionally, it makes it easy to access the data of referenced entities. In Drupal Commerce, I make extensive use of this functionality since a couple of our entities serve primarily as containers of references to other entities. An example approaching the usefulness you mention in your original post would be to have quick access to all the taxonomy terms referenced by a node. A simple way to do this with the wrapper would be to wrap the node and then loop over your taxonomy reference field's data to access the fully loaded term data. It's hard to demonstrate this without including extensive code snippets, but you can easily see how I put this to work by grepping the Drupal Commerce source for entity_metadata_wrapper.
The jury's still out on how useful or widespread the Entity API will be, but as it's a dependency of Rules 2, I doubt it's going anywhere soon. This may be a little too much information based on your response to electblake, but my hunch is the information should be useful for additional people who find this question when searching for more information on the Entity API. : )
I've been using the Entity API to create some new entities and bundles. Here's what I can report so far:
Using views: Pretty easy and straightforward, once you expose the module to views, describe the tables, etc. See: hook_views_data and the Advanced Help info about Views
Using taxonomy: (Sad trombone). The taxonomy tables store data by nid. That is, no way that I see to tell taxonomy to look in your entity's table. I've had to work around by creating my own version of the taxonomy_index table and glom onto taxonomy as best I can.
No experience with the other modules you mention, but I'm guessing the same principle will apply: if the module assumes nodes and nid, it won't work well with your entity. Otherwise, I'd guess you can get things integrated.
The easiest and most consistent way to handle entities is by using the Entity API module:
This module extends the entity API of Drupal core in order to provide a unified way to deal with entities and their properties. Additionally, it provides an entity CRUD controller, which helps simplifying the creation of new entity types.