2

Update, After I added IReturn to my GetMember Class like this

[Route("/member")]
[Route("/member/{member_id}")]
public class GetMember:IReturn<CommonResponse>
{
    public int member_id { get; set; }
}

I now can successfully build my swift code. But, the response seems to be missing some key property.

CommonResponse is defined as such

public class CommonResponse
{
    public int recordcount { get; set; }
    public object data { get; set; }

}

This is my swift code

var client = JsonServiceClient(baseUrl: "http://localhost/api/")
let response:CommonResponse = client.get(req, error: &error)!
println(response.toJson())

And What I've got is this

{"recordcount":1}

Missing very important property: data

Please help again, thanks!!!

Below has been fixed by adding a IReturn to my DTO GetMember class

I've been reading and trying to call servicestack based API from swift. Basically I've read this post https://github.com/ServiceStack/ServiceStack/wiki/Swift-Add-ServiceStack-Reference

I've successfully generated swift codes from my api

But when I wrote this in my iOS swift project

let req = GetMember()
req.member_id = 3
var error : NSError?
var client = JsonServiceClient(baseUrl: "http://localhost/api/")
let response = client.get(req, error: &error)

I can't successfully build it. Error for the last line: Cannot invoke 'get' with an argument list of type '(GetMember,error:Inout NSError?)'

Please help me

shawhu
  • 1,217
  • 1
  • 12
  • 27

1 Answers1

1

Does the GetMember Request DTO have an IReturn<T> interface defined on it? If not you'll need to specify it on the call-site, i.e:

var response:GetMemberResponse = client.get(GetMember())
mythz
  • 141,670
  • 29
  • 246
  • 390
  • OK, thanks, it fixed my problem. But new new came. I have this. Public class GetMember:IReturn CommonResponse is one of my classes. It has 2 properties. RecordCount as Int and Data as object. Now my returned response in swift only has recordcount but missing Data. – shawhu Aug 13 '15 at 23:26
  • @shawhu See [the Swift Limitations](https://github.com/ServiceStack/ServiceStack/wiki/Swift-Add-ServiceStack-Reference#swift-native-types-limitations), don't create `object` or `interfaces` properties. – mythz Aug 13 '15 at 23:56
  • Thanks for the reply @mythz . I got the idea. I fully understand that using interface is not a good idea for DTOs but just for the sake of this case, I need to return a standard return format (CommonResponse) and I happen to have to implement a property that can return general type (as object). What do you recommend? What is the proper way to do it? OR are you saying this is not proper way to do it because the idea of CommonResponse is not a good practice so that I should define separated return responses for each request DTOs? – shawhu Aug 14 '15 at 00:43
  • @shawhu returning an `object` is telling consumers of your Service they can't predict what the Service returns because the response is completely undefined which is an anti-pattern for Services which should be self-describing. You can either flatten the Types so different types fit into the same schema or [have a containing Type containing multiple different concrete Types](http://stackoverflow.com/questions/10750571/getting-servicestack-to-retain-type-information/10759250#comment27560838_10759250) – mythz Aug 14 '15 at 01:43
  • I think I got it. But just to be clear. What you mean is either we make a return type that can work for GetMember GetPayCheck GetMemberFriends, which I don't think we can, OR, we can make a type that has a lot of properties, one for each request type? OR we can make separate return types for each requesting DTOs, I think the last one is the proper way to do it, right? – shawhu Aug 14 '15 at 02:28
  • @shawhu Firstly I'd never design a Service that can have different response Types since ideally [Services should be grouped by Response Type and call semantics](http://stackoverflow.com/a/15941229), so I'd never have this problem. For an example of Containing Type holding different Types see [DynamoDb Item AttributeValue](http://amzn.to/1hANx2T) otherwise if you're using inheritance than it's likely you can get away with a single flat type with merged fields and a 'Type' field to indicate what it is, i.e. same way how you'd store it in a flat RDBMS table. – mythz Aug 14 '15 at 03:03