I plan on consuming the REST services provided by ServiceStack outside of .NET. I plan to writing clients for java and obj-c. This should be easy since it is a REST service, however in the documentation it seems to suggest otherwise:
But ServiceStack includes two clients which are optimized for ServiceStack in aspects like exception handling etc.
How would I go about implementing a ServiceStack client with Android? Just follow normal REST consumption procedures? Should I worry about any exception handling issues?
Also, would authentication be an issue (I’ll be using BasicAuthentication)?
ServiceStack web services provide pure HTTP/REST APIs which are essentially just serialized POCO DTOs over the wire. You control the entire HTTP output as ServiceStack doesn’t add any additional cruft around your serialized payloads.
Expects Pure Serialized DTOs
The opinionated nature comes from the ServiceClients assuming that the services are just returning pure serialized DTOs (i.e. without additional cruft) which it simply deserializes as-is into the specified response type. The ServiceClients are unique in that they give you a strong-typed end-to-end API without any code-gen since you’re able to re-use the POCO DTOs you defined your web services with.
Fallback to pre-defined routes
The APIs that don’t speicfy a
relativeOrAbsoluteUriin the API like the Send<TResponse>(dto) will by default use the pre-defined routes automatically provided by ServiceStack allowing you to call web services without needing to specify any Custom routes for them. You can of-course opt to use your custom routes instead by sticking to the IRestClient and IRestClientAsync APIs which allow you to specify the url to use.Automatic Error Handling
The C# ServiceStack ServiceClients are optimized in that by convention ServiceStack web services will serialize structured error responses in a ResponseStatus property on your Response DTO (only if it has one). All the service clients do is just de-serialize the error response into a typed C# WebServiceException which gives your C# clients strong-typed access to structured errors as explained in detail in the Validation wikipage.
Basically the ResponseStatus property is just a convention (not some anti-REST magic) and you still control what HttpStatus Code and Description gets returned. It’s simply another pure DTO property that all REST clients have equal access to – here’s a simple JavaScript ss-validation.js routine that extracts the responseStatus metadata and injects the errors onto a Twitter Bootstrap HTML Form.