CODEWITHSUNDEEP
c#servicestack
Giedrius
Giedrius

Reputation: 8540

What naming convention should I use in Service Stack service model?

We are thinking about using ServiceStack in our next project; and while looking at examples, I've noticed, that there's no common naming convention. For example:

entity: Movie
request: Movie
response: MovieResponse

The same goes for all operations. Now this example:

entity: Answer
request: Answers
response: AnswerResult

Yet another:

entity: User?
request: GetUsers
response: GetUsersResponse

(it is kind of weird to see class names staring with verb)

So, may be you have come up with some clever naming convention and would like to share. Also, are there any larger open source projects on service stack, where I could look how they organize their service model?

Upvotes: 8

Views: 2565

Answers (2)

user166390
user166390

Reputation:

I use BREAD1 and Verb-Entity with the following styles:

Namespace is "Entities", then:

  • BrowseEntities
  • BrowseEntitiesResponse
  • BrowseEntitiesService
  • AddEntity
  • AddEntityResponse
  • AddEntityService

Note the form is really [Verb][Entity][Role].

  • Verbs: Browse, Read, Edit, Add, Delete (BREAD), Validate, Extract (e.g. other operations)

  • Entity: This is plural or singular, depending upon the normal number of affected / retrieved entities. (I'm not entirely discounting that a service like DeleteEntity might delete multiple entities at a time, but careful consideration should be given if put into a "singular"-name DTO/service. It could always follow the plural DeleteEntities.)

  • Role: (Nothing) = Request DTO, Reponse = Response DTO, Service = Service.

  • Namespace: Always plural. This avoids conflicts with DAL classes like Entity (singular).

For the BREAD bindings (endpoint is always plural, it represents a collection):

  • /entities GET - BrowseEntities
  • /entities/Id GET - ReadEntitiy
  • /entities/Id POST - EditEntity (not sold on PUT; have not looked into PATCH support)
  • /entities POST - AddEntitity
  • /entities/Id DELETE - DeleteEntity

Misc. binding guidelines:

  • /entities/Id/verb POST/GET - VerbEntity (i.e. ValidateEntity), GET only if idempotent.
  • /entities/_/verb POST/GET - VerbEntitiy, applies to arbitrary (but specific) entity that has no resource identified with it. This is rare, but used in cases such as validating a not-yet-saved entity. It allows the pattern to otherwise be kept consistent.
  • /entities/verb POST/GET - VerbEntities, applies to collection but not any particular resource.
  • /entities/Id/items/.. - a child/related endpoint, relating to the entity with the given Id. Follows the same patterns previously discussed.

1 Unfortunately, BREAD appears to be a fringe term. From the CRUD wikipedia article:

Another variation of CRUD is BREAD, an acronym for "Browse, Read, Edit, Add, Delete".

I prefer how it sounds and that it has a separate Browse action.

Upvotes: 14

Michael Josiah
Michael Josiah

Reputation: 148

I currently use the third option where the request starts with the verb. Reason being my implementation is not entirely based on typical REST style urls and I use the c# clients extensively. In this scenario the verbs just helps to clearly identify the purpose of the service.

Apart from my particular scenario I would go with

entity: Movie request: Movie response: MovieResponse

Upvotes: 4

Related Questions