What is the best practice to implement batch requests with GWTP using RequestBuilder. I need to get data from php server using JSON.
Related
There are a lot of answers on how to convert ODataQuery into an Expression or into a Lambda, but what I need is quite the opposite, how to get from a Linq Expression the OData query string.
Basically what I want is to transcend the query to another service. For example, having 2 services, where your first service is not persisting anything and your second service is the one that will return the data from a database. Service1 sends the same odata request to Service2 and it can add more parameters to the original odata request to Service2
What I would like:
public IActionResult GetWeatherForecast([FromServices] IWeatherForcastService weatherForcastService)
{
//IQueryable here
var summaries = weatherForcastService.GetSummariesIQ();
var url = OdataMagicHelper.ConvertToUri(summaries);
var data = RestClient2.Get(url);
return data;
}
OP Clarified the request: generate OData query URLs from within the API itself.
Usually, the queries are so specific or simple, that it's not really necessary to try and generate OData urls from within the service, the whole point of the service configuration is to publish how the client could call anything, so it's a little bit redundant or counter-intuitive to return complex resource query URLs from within the service itself.
We can use Simple.OData.Client to build OData urls:
If the URL that we want to generate is:
{service2}/api/v1/weather_forecast?$select=Description
Then you could use Simple.OData.Client:
string service2Url = "http://localhost:11111/api/v1/";
var client = new ODataClient(service2Url);
var url = await client.For("weather_forecast")
.Select("Description")
.GetCommandTextAsync();
Background, for client-side solutions
If your OData service is a client for another OData Service, then this advice is still relevant
For full linq support you should be using OData Connected Services or Simple.OData.Client. You could roll your own, or use other derivatives of these two but why go to all that effort to re-create another wheel.
One of the main drivers for a OData Standard Compliant API is that the meta data is published in a standard format that clients can inspect and can generate consistent code and or dynamic queries to interact with the service.
How to choose:
Simple.OData.Client provides a lightweight framework for dynamically querying and submitting data to OData APIs. If you already have classes that model the structure of the API then you can use typed linq style query syntax, if you do not have a strongly typed model but you do know the structure of the API, then you can use either the untyped or dynamic expression syntax to query the API.
If you do not need full compile-time validation of your queries or you already have the classes that represent the resources served by the API then this is a simple enough interface to use.
This library is perfect for use inside your API logic if you have need of generating complex URLs in a strongly typed style of code without trying to generate a context to manage the connectivity to the server.
NOTE: Simple.OData.Client is sometimes less practical when developing against a large API that is rapidly evolving or that does not have a strict versioned route policy. If the API changes you will need to diligently refactor your code to match and will have to rely on extensive regression testing.
OData Connected Services follows a pattern where some or all of the API is modelled in the client with strongly typed client side proxy interfaces. These are POCO classes that have the structure necessary to send to and receive data from the server.
The major benefit to this method is that the POCO structures, requests and responses are validated against the schema of the API. This effectively gives you full intellisense support for the API and allows you to explor it's structure, the generated code becomes your documentation. It also gives you compile time checking and runtime safety.
The general development workflow after the API is deployed or updated is:
Download the $metadata document
Select the Operations and Types from the API that you want to model
Generate classes to represent the selected DTO Types as defined in the document, so all the inputs and outputs.
Now you can start using the code.
In VS 2022/19/17 the Connected Services interface provides a simple wizard for establishing the initial connection and for updating (or re-generating) when you need to.
The OData Connected Service or other client side proxy generation pattern suits projects under these criteria:
The API definition is relatively stable
The API definition is in a state of flux
You consume many endpoints
You don't want to manually code the types to serialize or deserialze payloads
Full disclosure, I prefer the connected service approach, but I have my own generation scripts. However if you are trying to generate OData query urls from inside your API, its not really an option, it creates a messy recursive dependency... just don't go there.
Connected services is the low-(manual)-code and lazy approach that is perfect for a stable API, generate once and never do it again. But the Connected Service architecture is perfect for a rapidly changing API because it will manage the minute changes to the classes for you, you just need to update your client side proxy classes more frequently.
Say, I have a feature in my app that relies on an external API - I provide an interface, which makes calls to my server, and the server, relying on that, makes some calls to some external API and responds something to client. If I wanna write an acceptance test with cucumber for that, how can I stub the calls to that external API, so, e.g. any GET call to https://www.cool-api.io/foo would just immediately return some-predefined JSON response with some predefined headers, any POST request to that url would return a response with some predefined status and headers, etc. How do you do it for acceptance tests if you're using cucumber?
We use WireMock or MockServer for this. You can implement them to stub API calls.
Also, I'd recommend using a framework like Jackson to generate json from domain objects. The benefits of this are not having to maintain json Strings/docs in your code base, and compile time checks on whether you created valid domain objects in your test.
I would probably write my own stub that was able to fake an implementation of the response with the expected content and headers set. If the response object is defined with an interface, then have your hand rolled stub to implement that interface.
Using Mockito for this would probably be to cumbersome in my opinion. Mockito is great, but setting up a complex return value like this may be messy. Hard coding the responses in an implementation of a response interface may be easier.
I would check the actual integration towards the external service using other tooling than Cucumber.
I am playing around with the ASP.NET vNext. and I was wondering how to create my own context per request.
In older versions I would create a singleton and store it in HttpContext.Current.Items.
The idea is that I want to load some data at the beginning of the request that should be available through the entire request.
You can achieve the same with HttpContext Items. You would write a middleware like this one and you can handle your stuff inside the Invoke method.
We're currently working on a Worklight project using Dojo (more specifically dojox/app). We managed to create a basic example with a store, model, controller and a view. However, now we want to connect this to our Worklight adapter.
What is the best approach in connecting a Dojox/app application to the backend? We were thinking about feeding our store with the data from the Worklight adapter, however, we need to do all CRUD operations and our data should be in sync with the server because multiple users might be working at the same item.
The best general solution I can think about is using a JsonRest store, but we're using the WL.Client.invokeProcedure function that calls our adapter, so we're not directly using the service.
We found a solution by using the WL.JSONStore from WorkLight. The API of it isn't compatible with the dojo/store API (logically since it wasn't meant to be), but we wrote a dojo/store API based proxy class which does nothing more than translating and forwarding calls to the WL.JSONStore.
I am attempting to implement a reverse proxy using the RequestInterceptor from WCF REST starter kit. I am able to set the basic header properties and configure the calls. I am getting stuck with the following aspects:
Returning an appropriate response - my webservice can return text+xml, image or json. I am not able to send the appropriate response type. The Message.CreateMessage overloads are all SOAP aligned i.e. they accept only Xml constructs, so I am not able to send either JSON or image streams. I need to convert them into XElements - I am definitely doing something wrong here.
I also want the reverse proxy to be functioning well in the presence of cookies, gzip/deflate and SSL.
Based on the above requirements, do you think it makes sense to do this using REST starter kit? The Requestinterceptor was fairly easy to plug into, however the rest of the code is driving me nuts.
There is a mapping between both JSON and arbitrary binary content to XML which is used in messages for WCF (see some examples at http://blogs.msdn.com/b/carlosfigueira/archive/2011/04/19/wcf-extensibility-message-inspectors.aspx), so you can use Message.CreateMessage to create non-XML messages as well.
Having said that, it's really not intuitive to do that in WCF as of now. The new libraries in the WCF Web API - http://wcf.codeplex.com - provide a very nice way of intercepting / redirecting / bypassing the WCF pipeline especifically for HTTP messages. Also, it support multiple formats in a native way (i.e., without need to do some mapping to XML).