CODEWITHSUNDEEP
c#servicestackrestful-url
Tom
Tom

Reputation: 16276

ServiceStack New API Actions matching Rest Verbs

With the older version SomeService : RestServiceBase can match OnGet OnPost OnPut OnDelete actions with the coresponding incoming verbs.

With the newer version, say I have the following:

//-----------------------------------------
[Route("/todos/{id}","GET")] //display request
[Route("/todos/{id}", "POST")] //edit request
public class Todo : IReturn<TodoResponse> {
    public long Id { get; set; }
    public string Content { get; set; }
}

public class TodoService : Service {
    public object Get(Todo request) { ... } // will GET verb know this Get() function?
    public object Post(Todo request) { ... }// will POST verb know this Post() function?
}

The Action names "Get" "Post" are no longer marked "override", how does SS match the correct verbs to hit Get() and Post() functions?

//--------------------------------------------------------------------------

Or Round 2, now I have a modification...

//-----------------------------------------
[Route("/todos/{id}","GET")] //display request
public class DisplayTodo : IReturn<TodoResponse> {
    public long Id { get; set; }
}
[Route("/todos/{id}", "POST")] //edit request
public class EditTodo : IReturn<TodoResponse> {
    public long Id { get; set; }
    public string Content { get; set; }
}

public class TodoService : Service {
    //different request DTOs this time ...
    public object Get(DisplayTodo request) { ... } //again, same route "/todos/{id}" 
    public object Post(EditTodo request) { ... }   //will SS get confused about the verbs? 
}

Under the same route "/todos/{id}" how does SS distinguish verbs in the above cases?

Could you please sort me out with the 2 questions? Thank you!

Upvotes: 3

Views: 2042

Answers (2)

mythz
mythz

Reputation: 143399

This is the Smart Routing section taken from the New API wiki page:

Matching Rules

For the most part you won't need to know about this as ServiceStack's routing works as you would expect. Although this should still serve as a good reference to describe the resolution order of ServiceStack's Routes:

  1. Any exact Literal Matches are used first
  2. Exact Verb match is preferred over All Verbs
  3. The more variables in your route the less weighting it has
  4. When Routes have the same weight, the order is determined by the position of the Action in the service or Order of Registration (FIFO)

These Rules only come into play when there are multiple routes that matches the pathInfo of an incoming request.

Lets see some examples of these rules in action using the routes defined in the new API Design test suite:

[Route("/reqstars")]
public class Reqstar {}

[Route("/reqstars", "GET")]
public class AllReqstars {}

[Route("/reqstars/{Id}", "GET")]
public class GetReqstar {}

[Route("/reqstars/{Id}/{Field}")]
public class ViewReqstar {}

[Route("/reqstars/{Id}/delete")]
public class DeleteReqstar {}

[Route("/reqstars/{Id}", "PATCH")]
public class UpdateReqstar {}

[Route("/reqstars/reset")]
public class ResetReqstar {}

[Route("/reqstars/search")]
[Route("/reqstars/aged/{Age}")]
public class SearchReqstars {}

These are results for these HTTP Requests

GET   /reqstars           =>    AllReqstars
POST  /reqstars           =>    Reqstar
GET   /reqstars/search    =>    SearchReqstars
GET   /reqstars/reset     =>    ResetReqstar
PATCH /reqstars/reset     =>    ResetReqstar
PATCH /reqstars/1         =>    UpdateReqstar
GET   /reqstars/1         =>    GetReqstar
GET   /reqstars/1/delete  =>    DeleteReqstar
GET   /reqstars/1/foo     =>    ViewReqstar

And if there were multiple of the exact same routes declared like:

[Route("/req/{Id}", "GET")]
public class Req2 {}

[Route("/req/{Id}", "GET")]
public class Req1 {}

public class MyService : Service {
    public object Get(Req1 request) { ... }     
    public object Get(Req2 request) { ... }     
}

The Route on the Action that was declared first gets selected, i.e:

GET /req/1              => Req1

Upvotes: 4

Alexis
Alexis

Reputation: 384

ServiceStack will try to match both the request VERB and its request DTO. If either one of them do not match, you'll get a no request handler message.

Your examples seem to be fine, have you encoutered any problem with them ?

Upvotes: 4

Related Questions