Does it Make Sense to have ViewModels in the Webapi?

Terminology aside, having models for binding to is still of use. They just aren't technically ViewModels anymore, in that you're right there are no views involved. But they are definitely still of use. Using them allows you to take advantage of attributes on your Model's properties and allows you to reuse them across your API if needed. Also remember if you use your entities directly WebAPI will model bind all parameters to them that match by name, even if you didn't mean to.

Also, the Entity Models are representations of your raw data, but the Models used for binding against are a fixed contract that the API requests need to satisfy to successfully process a request. The values in which, could end up spanning multiple entity models by the time your implementation is done, and not be persisted to a data store at all.

My suggestion after loooong time working with this 'things' :

BindingModels for data binding (mvc or api)

ViewModels for views on mvc (you may have some mvc pages inside your api, so it's good to have a place for this, this can be documentation, intro page, whatever. If there is none view, then you can have zero ViewModels) One benefit of this is that you can in your Views/web.config have the ViewModels namespace reference and it won't be polluted with your api resources.

ResourceModel for web api resources. In webapi, nested resources are also resources that go anywhere in a tree which is not that common on mvc, so naming them resources make a lot of sense.

If you want to receive a resource, you can use your resource model. Remember your are receiving the same your are sending back.

If you want a custom binding for input (this should be your default scenario) you have your binding models.

If you have any mvc view, for admin purposes, documentation, whatever, use your ViewModels.

If you have a form page on mvc, you can use your BindingModel also on the POST controller. No need to have a different model for a post on MVC or WEBAPI. Specially when model binder or formatter can both understand and map to the same binding model using the same Data Annotations.

Sometimes, you want to create a binding model with a resource and some extra fields. Inheritance is your friend.

Sometimes you want to create binding model with more than one resource and (optionally, extra fields) Resources as properties are your friend.

In MVC world, you can also use the concept of 'Resource' but it is much less common. This come in handy when you have MVC and Web Api on the same project.

If you need further comments on any item (like folder structure, namespaces, etc), just let me know. I'm more than happy to share my cons pros experience.

Oh, and I forgot, a mapping strategy is worth research. I personally do my own mappings, but having this logic in one place is priceless.

EDIT: Very naive example

ContactViewModel{

    string Name {get;}
    string LastName {get;}
    List<Country> AvailableCountries {get;}
    Country Country {get;}
    bool IsAdmin {get;}

}

ContactBindingModel{

    string Name {get;set;}
    string LastName {get;set;}
    int Country {get;set;}

}

ContactResourceModel{

    string Name { get;set;}
    string LastName {get;set;}
    Country Country {get;set;}
    string IsAdmin {get;}

}