I'd be curious to see what the community thinks of the naming convention used to name methods the new version of the API.
IMHO it's not necessary to reflect in the method name the underlying HTTP verb and parameters.
For example:
The ItemsIdPut could be simply named UpdateItem(int id) reading the code it's obvious the method takes the ID, and the underlying PUT verb is an implementation detail as far consuming the API goes?
The same logic would apply to all the other methods:
CategoriesCategoryIdGet should be GetGategory(int id) (here Get would happen to match the HTTP verb but that would be a coincidence.
ItemsPost() would become CreateItem(Item item)
...
Better yet, the API could be broken down into services per kind of entity retrieved. E.g. you'd have an you'd instanciate an ItemService, a CategoryService and each would have a set of Get, Update and Create methods...?
As an aside, if the current naming convention is deemed the better one, the GetToken method doesn't follow it.
Hello,
Nice to see some activity in this project.
I'd be curious to see what the community thinks of the naming convention used to name methods the new version of the API.
IMHO it's not necessary to reflect in the method name the underlying HTTP verb and parameters.
For example:
ItemsIdPutcould be simply namedUpdateItem(int id)reading the code it's obvious the method takes the ID, and the underlying PUT verb is an implementation detail as far consuming the API goes?CategoriesCategoryIdGetshould beGetGategory(int id)(here Get would happen to match the HTTP verb but that would be a coincidence.ItemsPost()would becomeCreateItem(Item item)Better yet, the API could be broken down into services per kind of entity retrieved. E.g. you'd have an you'd instanciate an
ItemService, aCategoryServiceand each would have a set of Get, Update and Create methods...?As an aside, if the current naming convention is deemed the better one, the
GetTokenmethod doesn't follow it.Looking forward to read people's opinions.