Domain Service	The back-end service that the Domain Model represents - i.e. the service that exposes the API.
Domain Model	The definition or documentation of the API exposed by the user’s Domain Service.
This refers to the file written in the Veneto language, or alternatives such as OpenAPI.
Implementation Platform	The programming language, library, or API that the user is using to perform or serve HTTP Requests.
The client aspect is being considered in ‣
Implementation Client/Server	The client or server that the user implements. The Implementation Server is what exposes the API for the Domain Service, but specifically refers to the HTTP server code rather than the web service in the abstract.
Design Tools	Includes the language and IDE, as well as validation tools
Medium	The serialization language or standard used to encode API response data
Resource	An entity represented by a URI. In HTTP, this includes all of the methods available on a given URI.
‣	A “Type” of resource, which has a defined behavior. Multiple resources can share the same Resource Class.
User	Without any further context, “the user” by itself refers to the user of Veneto. This can be an API designer, a user of the Test Client, or a programmer using the toolkit.
(We could use some more rigorous domain modeling of our own to formalize these actor types)
End User	An End User, on the other hand, is the user of a product created using a Veneto API. All the way down the chain.
URI Scheme	The Domain Service’s internal system for assigning URIs to Resources. With the exception of entry points, this should be completely abstracted away from the client, so that the client never needs to construct a URI. This is accomplished through Links to Resource Classes; see ‣