My custom entity is exposed and implemented by an ABAP class (implementing interface if_rap_query_provider). I can get data via OData V2.
But the HTTP request header fields are hidden by the SAP framework so I can't use them in my if_rap_query_provider~select implementation. Is there a solution to get the request header fields in the implementing class?
I have to transfer additional data from client to server (besides the data model) that must be handled by our backend business logic.
Environment: ABAP 7.54 / 1909 / OnPremise
Anyone know how to solve it?
Related
The new WSO2 API MicroGateway 3.0 states as new feature Support for composing multiple microservices.I cannot find an example of how to do that.
We are trying a use case with just this type of processing:
An API that queries a back-end database using OData and if not found queries another (non OData) API.
In both cases the result must be transformed (reformatted).
Idea of composing microservices, is to expose set of microservices as a single API using microgateway. Basically you can define define set of REST resources and then point them to different microservices. For ex:
/list . -> micro service1
/add -> micro service2.
You can define per resource back ends using swagger (open API) extensions as below
https://github.com/wso2/product-microgateway/blob/master/samples/per_resource_endpoint.yaml
As of now microgateway does not have out of the box capability to call subsequent endpoints based on the response from the previous endpoint.
But you can transform the response using the response interceptors as explained below link
https://docs.wso2.com/display/MG300/Adding+Interceptors
I want my OData service to support Json serialization, I read about a WCF Data Service toolkit which add this behaviour to the V2 version. After I read WCF Data Service released a new version of WCF Data Service 5.0, I need to know how to do it.
I add the $Format=json and I get all the time this attribute isn't supported.
Any suggestion .
Thanks in advance ...
The usual way to request JSON is to use Accept header (basically following HTTP, if the client wants a certain representation of the response, it should ask for it in the Accept header).
So if you send Accept: application/json;odata=verbose, you will get the Verbose JSON response.
WCF Data Services currently doesn't implement the $format query option. But you can add it "on top". There are several ways to do this (just search the web). One of them is for example here: http://archive.msdn.microsoft.com/DataServicesJSONP
Assume i've read a lot about versioning a restful api, and I decided to not version the the service through the uri, but using mediatypes (format and schema in the request accept header):
What would be the best way to implement a wcf service or a web api service to serve requests defining the requested resource in the uri, the format (eg. application/json) and the schema/version (eg player-v2) in the accept header?
WCF allows me to route based on the uri, but not based on headers. So I cannot route properly.
Web Api allows me to define custom mediatypeformatters, routing for the requested format, but not the schema (eg. return type PlayerV1 or PlayerV2).
I would like to implement a service(either with WCF or Web Api) which, for this request (Pseudo code):
api.myservice.com/players/123 Accept format=application/json; schema=player-v1
returns a PlayerV1 entity, in json format
and for this request:
api.myservice.com/players/123 Accept format=application/json; schema=player-v2
returns a PlayerV2 entity, in json format.
Any tips on how to implement this?
EDIT: To clarify why I want to use content negotiation to deal with versions, see here: REST API Design: Put the “Type” in “Content-Type”.
What you are bringing here does not look to me as versioning but it is is more of content negotiation. Accept header expresses wishes of the client on the format of the resource. Server should grant the wishes or return 406. So if we need more of a concept of Contract (although Web API unline RPC does not define one) then using resource is more solid.
The best practices for versioning have yet to be discussed fully but most REST enthusiast believe using the version in the URL is the way to go (e.g. http://server/api/1.0.3/...). This also makes more sense to me since in your approach using content negotiation server has to keep backward compatibility and I can only imagine the code at the server will get more and more complex. With using URL approach, you can make a clean break: old clients can happily use previous while new clients can enjoy the benefits of new API.
UPDATE
OK, now the question has changed to "Implementing content-negotiation in a RESTful AP".
Type 1: Controller-oblivious
Basically, if content negotiation involves only the format of the resource, implementing or using the right media type formatter is enough. For example, if content negotiation involves returning JSON or XML. In these cases, controller is oblivious to content negotiations.
Type 2: Controller-aware
Controller needs to be aware of the request negotiation. In this case, parameters from the request needs to be extracted from the request and passed in as parameter. For example, let's imagine this action on a controller:
public Player Get(string schemaVersion)
{
...
}
In this case, I would use classic MVC style value providers (See Brad Wilson's post on ValueProviders - this is on MVC but Web API's value provider looks similar):
public Player Get([ValueProvider(typeof(RequestHeadersSchemaValueProviderFactory))]string schemaVersion)
{
...
}
I’m trying to write an OData service in C#2010 that exposes some POCO to a jQuery web client via JSON, but also allows updates to the underlying data. I’ve found lots of examples of read-only POCO data via OData and lots of examples of updatable data via Entity Framework and OData.
My problem is that the data is in a proprietary database so there needs to be a business logic layer to handle the DB updates and I don’t see where this fits in the OData/WCF Data Services model. I’m populating the POCO entities using IQueryable lists and exposing them using SetEntitySetAccessRule, but how do I call a method in the business logic/data model layer to persists data to the DB?
Should I be using SetServiceOperationAccessRule to expose service methods? If so, could anyone point me in the direction of a simple example please?
Thanks
My suggestion would be a custom WCF Data services provider, so that you can have a custom implementation of IDataServiceUpdateProvider. There is a good blog series at http://blogs.msdn.com/b/alexj/archive/2010/01/07/data-service-providers-getting-started.aspx
Rich's suggestion to implement IUpdatable/IDataServiceUpdateProvider is correct. That's the way to support Update operations (the EF provider implements this in-box, the reflection provider doesn't so you have to do that yourself).
You can implement IUpdatable even when using reflection provider. Just make your context class (the one you pass in as T to DataService) implement the IUpdatable interface.
I wrote some WCF server that support SOAP.
Now, i need to add some new request ... to add support in REST in some of the method that are supported SOAP.
I don't know how to do it.
Actually one of those method need to change to support REST.
How to do it ?
Add WebHttpBinding and a new service contract interface with the relevant REST methods annotated with UriTemplate. Encapsulate your business logic in a class that is used by soap service class and the rest service class both.