The Problem
I'm aware of the basic way to create a route/endpoint in ServiceStack using methods with names like "Get", "Post", "Any", etc inside a service but in the particular case that I'm trying to work with I have an existing service (which I can make an IService via inheritance) that can not be retrofitted w/ServiceStack attributes and currently uses DTOs for the requests and responses.
This service contains many functions that I do not want to manually mask (as this is a pass-through layer) but otherwise already conform to ServiceStack's requirements. What I'm wondering is if there's a way to manually create these routes in a way that would work like I've mocked up here. My existing functions and DTOs already contain the information I would need to define the routes so if this approach is possible it would only require me to enumerate them at initialization time as opposed to generating the services layer manually.
I noticed there is an extension method on Routes.Add that takes an Expression of type Expression> but I was not able to get that working because I believe the underlying code makes assumptions about the type of Expression generated (LambdaExpression vs MemberExpression or something like that). I also may be barking up the wrong tree if that's not the intended purpose of that function but I can not find documentation anywhere on how that variant is supposed to work.
Why?
I'm not sure this is necessary but to shed some light on why I want to do this as opposed to retrofitting my existing layers: The current code is also used outside of a web service context and is consumed by other code internally. Retrofitting ServiceStack in to this layer would make every place that consumes it require ServiceStack's assemblies and be aware of the web service which is a concern I want separated from the lower code. We were previously using MVC/WCF to accomplish this goal but we want some of the features available from ServiceStack.
the current architecture looks like this:
data -> DAL -> discrete business logic -> composition -> web service
Hopefully that makes enough sense and I'm not being obtuse. If you would like any more details about what I want to do or why I'll try to update this post as soon as possible.
Thanks!
You might use the fallback route in order to provide your own routing mechanism.
Then you get the request.Path property and route using your own mapping of path:Function which can be stored in a simple dictionary.
Anyway, if you go this path I don't see much benefit in using servicestack. It seems you just need an http handler that routes requests to existing services.
Related
Summary
I am seeing a lot of contradictory architectural examples of a REST API in my work and keep getting different opinions on the subject.
I am familiar with the principles of REST and seeing as each endpoint points to a resource followed by a verb such as /project/create project/123/read.
Following the MVC pattern assuming I have a controller that is responsible for updating a project resource:
router.put("/project/:id/update", ProjectController.put)
First question:
Should this route be responsible for all updates to this resource, in example, assuming different features on my client like marking a project as finished or changing it's title are separated and might not have anything in common for the user. Ending up with the route described above, or should there be something like this:
router.put("/project/:id/mark-as-done", ProjectController.markAsDone)
router.put("/project/:id/update-info", ProjectController.updateInfo)
Second question:
Assuming I want to create a notification resource if a project is created/updated/deleted. Since the notification is a resource on it's own I am not sure how to go about this, but what I assumed and was taught is to use another callback:
router.put("/project/:id/update", ProjectController.put, NotificationController.create)
Third question:
Could I use the same controller to read all resources or just one, for example:
router.get("/project/read", ProjectController.get)
router.get("/project/:id/read", ProjectController.get)
Making the logic in the controller method determinate if it will return all projects or just one. Or should it be separated into different methods?
I would define APIs like this:-
CRUD for Project entity
create- router.post(/projects)
update:- router.put(/projects/:id)
delete:- router.delete(/projects/:id)
read:- router.get(/projects) and/or router.get(/projects/:id)
You can define all above routes in ProjectController.
Regarding Notification entity you can define as follows
read:- router.get(/projects/:id/notifications)
The same can be applied to PUT, DELETE, POST
Here is a good article defining rest guidelines https://stackoverflow.blog/2020/03/02/best-practices-for-rest-api-design/
I would like to add some common authentication code to a collection of HttpTrigger Azure Functions (v3), which I'm using as an API. I know about the service-side auth associated with AuthorizationLevel.Function, but that won't work for me. The type of auth I need to do is relatively simple: just check a specific HTTP header for a specific value.
In ASP.NET, this kind of thing can be done in an HttpModule. Do Azure Functions have a similar request pipeline of some kind?
As far as I can tell from the documentation, it looks like new Function instances can call Startup.Configure() before calling the target method, if the project is appropriately configured. However, those calls are intended to support Dependency Injection, and don't have access to the HttpRequest object.
Obviously, I could just put an isAuthorized(request) call at the beginning of each API entry point, but that feels klunky, repetitive, and potentially error-prone. Is there a better way?
Edited left name of a custom type instead of the direct service fabric interface.
I am trying to write an interceptor capable of interrogating the parameters being passed to a remoting service. I can intercept the IServiceRemotingRequestMessage once it gets to the service and am able extract the parameters, but ONLY if I know the position and name of the parameter at the time.
[Pseudo]
var someParam = IServiceRemotingRequestMessageBody.GetParameter(0, "request", serviceRequestInfo.RequestMessage.GetBody().GetType());
What I need is a way to simply iterate the parameters and work with them directly (currently just serialize them to a string so I can log some of the info being passed). However, the IServiceRemotingRequestMessageBody only exposes a GetParameter method that must be passed the index and the name...
I can maybe do some reflection work given the method name and the service contract but I'm hoping there is a much more straightforward way to get this directly.
Thanks for any tips,
Will
There may be an easier way using the default serialization, but the way I solved it, currently, is to replace the Service Fabric serialization providers with JSON Serialization. Then, my interceptors can work with the JSON data as necessary.
I'll assume there is a way to do something similar with the default serialization but, if so, it's not clearly documented how to work with it. If someone proposes an option I would gladly give it a try.
I have developed an application which was MVC application. It has a requirement that the application will return json data for one get request.
So I have added apicontroller and created a get method to return json data.
So far so good. but then I thought, is it really needed to add apicontroller to create just one get method.
I started exploring and googling what is the difference other than content negotiation. Got lots of answers and articles but non of them were satisfactory.
So here is the actual confusion, why can't I just create a method in the MVC controller with JsonResponse and return the json data(Which I know only is need for my requirement, but other application on different domain will consume it).
Can anyone convince me why should I use apicontroller instead of MVC JsonResponse for my requirement or should I not be using apicontroller at all.
apology if there is any mistake.
If I get it right the question is Can we use MVC action to serve json content answer is yes! Is it okay to use Json Result? answer is It depends where do you want to consume it
Say I am an in a Web Environment where I have no need for the APIs (that means I am not going to serve my data to multiple clients) If that's the scenario where only your View is going to consume data returned from your Action Method you are good to go. An Action returning a Json Result is basically an Action Result and that's what it is made for.
but If you are in a REST scenario and you need your backend to serve your data to the client de facto standard is to use an independent Web API for that.
Controllers' main responsibility should be to work as an intermediary between your View and Model and whatever service layer you want to bring inside it. on the other hand, Web APIs are data-driven there only purpose is to serve data (use them if you need them)
Web APIs are good cause they give you the flexibility of serving the data to possibly any client that might need it. That's what I would pick if I am starting from scratch but if I only need to serve data to one client Controller Action methods will be way to go.
Hope this helps.
I need to set up an application in Azure and make communicate 2 functions (one written in C# and one written in JavaScript).
The C# fragment consists in analyzing a XML feed, get the data and save in objects then finally send them to the other JavaScript function by parameter.
I did read that we could establish communication between both functions using HTTP calls but is it possible to do it with parameters ?
If not, would have any suggestions in order to achieve something like this properly? I'm getting started with Azure and i don't have enough visibility to know what is recommened in such a situation
Thank you for your advices
Yes, this is absolutely possible. How you do this is up to you. If you look at the default HTTP trigger templates, you can see that they take parameters (for example, as query string parameters). You can find more examples in the HTTP and webhook recipes documentation.
You can use other trigger types for cross-function communication as well. Take a look at this documentation for related best practices: https://learn.microsoft.com/en-us/azure/azure-functions/functions-best-practices#cross-function-communication