As ServiceStack Services are pure HTTP APIs they're accessible with any HTTP-capable client, but they're also capable of native client integrations with popular languages used to create Web, Mobile and Desktop Apps for maximum productivity and correctness.
The developer workflow is further simplified with IDE plugins that let you generate native client DTOs directly from your favorite IDEs:
Develop faster
Right Click, Integrate
Native client integrations for your APIs in all popular languages and IDEs
Support for all languages are implemented the same way where the generated DTOs can be used with idiomatic generic Service Clients giving developers a consistent way of creating and updating your DTOs regardless of your language of choice.
Command-line Tooling
The x dotnet tool also allows us to generate these native service references from the command-line with the format x <lang> <url>, e.g. we can create C# DTOs for our App with:
x csharp https://localhost:5001
Output:
Saved to: dtos.ts
Or create a TypeScript ServiceStack Reference with:
x typescript https://localhost:5001
Updating a ServiceStack Reference
To Update an existing ServiceStack Reference, call x typescript with the Filename, e.g:
x typescript dtos.ts
Result:
Updated: dtos.ts
This will update the File with your App's latest TypeScript Server DTOs. DTO customizations are also available by uncommenting the TypeScript DTO Customization Options and updating them again.
Updating all DTOs
Calling x typescript without any arguments will update all TypeScript DTOs in the current directory:
x typescript
Other available languages include:
| Script | Alias | Language |
|---|---|---|
| x csharp | x cs | C# |
| x typescript | x ts | TypeScript |
| x python | x py | Python |
| x java | Java | |
| x kotlin | x kt | Kotlin |
| x swift | Swift | |
| x dart | Dart | |
| x vbnet | x vb | VB.NET |
| x fsharp | x fs | F# |
ServiceStack Clients
To enable its clean end-to-end typed API development model, the generated DTOs can be used with a generic Service Client available for each supported language:
- C#/.NET Client
- TypeScript Client
- Kotlin Client
- Java Client
- Swift Client
- Dart Client
- JavaScript Client
- MQ Clients
Supported Languages
This Add ServiceStack Reference feature is available for all the popular supported languages below:
| C# | TypeScript | JavaScript | Python | Swift | Java | Kotlin | Dart | F# | VB.NET |
Development workflow preview
Here's quick walkthrough's installing the ServiceStack plugin and using it to add remote ServiceStack References in a new C# App:
TIP
VSCode and other IDEs will be able to use the command-line tool for adding and updating multiple Services references.
C# Xamarin.Android Example in VS.NET
Using C# to develop native Mobile and Desktop Apps provides a number of benefits including maximum reuse of your investments across multiple Client Apps where they're able to reuse shared functionality, libraries, knowledge, development workflow and environment in both Client and Server Apps.
Call ServiceStack APIs from a Flutter App with native Dart client and DTOs
Walk through showing how you can use ServiceStack's Dart client library with your Flutter Android application to quickly get up and running with Add ServiceStack Reference.
Call ServiceStack APIs from Python
This video tutorial looks at how we can leverage Add ServiceStack Reference for Python in PyCharm, VSCode and Python Jupyter Notebooks.
Instant Client Apps
Instant Client Apps is a free tool to jump start your native client application development using a wide range of languages and platforms including: C#, NodeJS, Dart, Java, Kotlin, Swift, VB .NET and F#:
gRPC
ServiceStack gRPC enables a highly productive development environment for developing high-performance gRPC HTTP/2 Services by making ServiceStack's existing typed Services available from ASP.NET's gRPC endpoints where ServiceStack offers a simplified development model for gRPC Clients for streamlined end-to-end productivity.
C# Mobile and Desktop Apps
The generated DTOs provides a highly productive development workflow and enables a succinct end-to-end Typed API that can be used in both .NET Framework and .NET Standard 2.0 Generic Service Clients to facilitate Rapid Development in .NET's most popular Mobile and Desktop platforms:
- WPF
- UWP
- Xamarin.Android
- Xamarin.iOS
- Xamarin.OSX
- Xamarin.Forms
- iOS
- Android
- UWP
The HelloMobile project contains multiple versions of the same App in all the above platforms demonstrating a number of different calling conventions, service integrations and reuse possibilities.
ServiceStack also allows for the maximum reuse possible by letting you reuse the same POCO DTOs used to define the Services contract with, in Clients Apps to provide its end-to-end typed API without any additional custom build tools, code-gen or any other artificial machinery, using just the DTOs in the shared ServiceModel.dll with any of the available highly performant .NET generic Service Clients that be design encourages development of resilient message-based Services for enabling highly decoupled and easily substitutable and mockable Service Integrations.
.NET Clients Message-based API
There are multiple C# service clients included, each optimized for their respective formats:
All clients share the same IServiceClient and IServiceClientAsync so they're easily swappable at runtime, and is what allows the same Unit test to be re-used as within an Xml, JSON, JSV, SOAP Integration test. The JSON, XML and JSV clients also share IRestClient and IRestClientAsync
What's the best way to expose our services to clients today?
Native language client libraries
A productive option for clients (and the recommended approach by ServiceStack) would be to provide a native client library for each of the popular languages you wish to support. This is the approach of companies who really, really want to help you use their services like Amazon, Facebook and Windows Azure. This is an especially good idea if you want to support static languages (i.e. C# and Java) where having typed client libraries saves end-users from reverse engineering the types and API calls. It also saves them having to look up documentation since a lot of it can be inferred from the type info. ServiceStack's and Amazons convention of having ServiceName and ServiceNameResponse for each service also saves users from continually checking documentation to work out what the response of each service will be.
Packaging client libraries
In terms of packaging your client libraries, sticking a link to a zip file on your Websites APIs documentation page would be the easiest approach. If the zip file was a link to a master archive of a Github repository, that would be better as you'll be able to accept bug fixes and usability tips from the community. Finally we believe the best way to make your client libraries available would be to host them in the target languages native package manager - letting end-users issue 1-command to automatically add it to their project, and another to easily update it when your service has changed.
Using NuGet
For .NET this means adding it to NuGet, and if you use ServiceStack your package would just need to contain your types with a reference to ServiceStack.Client. One of the benefits of using ServiceStack is that all your types are already created since it's what you used to define your web services with!