This is a question to improve my understanding about OData and the process of OData services. I'm not sure about the process when an OData request is sent to the server from my Fiori app. The app is added to our Fiori Launchpad. When the user wants to create a new target group in the UI, a create request is sent. What happens then in detail? What I thought so far:
OData service checks the data
If the data is valid, a new entry in the database is created (HTTP POST)
If the data is not valid, the OData service sends an error
I'm not sure about what information is delivered by the OData service and what information is delivered directly from the database? Does the OData service work like a adjustor which transfers the messages sent from the database to the application?
I hope you can understand what I'm trying to figure out. Thank you for your time.
it depends how your backend-methods are implemented. Every Entityset usually has one of these Methods:
Get Entity
Get EntitySet
Create
Update
Delete
There are some more I guess, but these are mostly used by developers. You can redefine every single method and implement your own Business Logic in there.
So, let's assume you want to send data from the Frontend to your service and insert the data into a table inside your database. You have to redefine the create method of your entity and implement own logic. This could contain an insert into a database-table. You have to consider, that your oData Service will throw an Error if the types which are sent from the frontend do not match the Entity-Types (i.e. a String into an edm.Time type).
Here you can find all EDM.Types oData could consume and the correct mapping of the types:
https://help.sap.com/saphelp_gateway20sp12/helpdata/en/76/4a837928fa4751ab6e0a50a2a4a56b/frameset.htm
Hope this helps :)
Related
I am using Angular2 as a client and for server side its ASP.NET WebAPI + EF6.
My DbContext is being shared for multiple DB operation within the same WebApi request. To share DbContext among multiple DB Operations, i am keeping DbContext in HttpContext.Current.Items["SameKey"].
So will it be unqiue on each WebApi call?
Although I'd recommend you to use an IoC module (e.g. Ninject) to manage the context's lifecycle - Yes HttpContext.Current.Items[] is guaranteed to be unique and persisted for the duration of the http request.
It's guaranteed to be unique. The HttpContext.Current.Items is only valid for a single request and when the request is sent back to a browser, its data will be flushed out automatically.
Please visit the following link for more information:
When Can We Use HttpContext.Current.Items to Store Data in ASP.NET
Hope this will help you
I have problem accessing database async.
My scenario is:
My application is based in ASP.NET, Web API & SignalR.
Using SignalR, I have send message to multiple to call update the data. That Javascript method call Web API method using AJAX to fetch data from database.
As the database connection is single; and at usthe same time request is trying to fetch data. So, all request serve instantly, but once the data fetch for one request and reader put all data in object and leave the method. It will create for all the other method call as the connection is closed.
Is any one has solution for this, how can I solve this.
Can you use a different instance of connection for each of the data reader?
My understanding of Asp.net restful web service is that for each resource , there are corresponding get,post,delete,put verbs.
But what if I have to submit a request to server that needs to operate on more than one resource?
e.g., for a submit form, I have to ask the server to create an order and in the same request a new order history.
For me , I define an order and an order history as two different resources.
And if we follow the ASP.NET MVC Web api restful web service, we will create two controllers, one named OrderController, and the other one OrderHistoryController.
And each controller has the “get,post,delete,put” verbs.
The question is how can we make sure that the creation of an order and the creation of an order history are in one transaction ?
How and when to call the OrderHistoryController’s post method to create an OrderHistory after the Order’s creation ?
I currently am not sure how to achieve this with OrderHistory being a resource.
Thanks for answering.
For starters, you probably won't want PUT and DELETE operations in OrderHistories. Being able to change/delete history generally isn't a good idea. (You probably don't even want a POST operation on that resource. The server-side logic should create its own OrderHistory objects any time an Order is created/modified/deleted.)
Aside from that...
You don't maintain a transaction (or, more generally, a unit of work) across multiple HTTP requests. Each request would be an isolated and otherwise atomic unit of work in and of itself.
So essentially what you're looking to do here is issue a POST to the Orders resource to create an Order object. The server-side logic in this operation would, within that same unit of work, also create any necessary corresponding records in OrderHistories.
Depending on how you select from these resources, you'd return information from that POST operation needed to query them. For example, it's unlikely that you'd ever want to query an OrderHistory by its own identifier right away, you'd probably query by the Order ID. So when creating an Order object, the returned server-generated ID for that object could be used by the client to query the OrderHistories if they want.
Ultimately, it sounds like the confusion here is from the mistaken notion that a RESTful service is basically a pass-through set of operations to database tables. It isn't. The consuming client shouldn't be responsible for maintaining transactional integrity or relational integrity. The server-side operations maintain that.
I want to implement a query on my web page that gets results from another web service and displays them to the user. For this I ofcourse send the request as GET method from the web page. Server side, I process the request, get results from that web service and return them back to user.
However, I also want to save the results for future refernce. Something like history of queries. For this I will store the results in a database.
Now, the question is since I am upating my database everytime a query is made, should I be using POST method on the web page or GET would do? Does HTTP explicitly say anything for this scenario?
HTTP itself doesn't say you have to use POST -- the technology will work just fine if you're sending your data on queryparams.
But current convention says that you should use POST, specifically when using API services under a RESTful model. If you are passing data (even on the query params) that is creating a new record, it should use the POST verb. Updating it should use PUT.
It's going to get down to what your audience expects. If it's just an internal resource, go for it with GET. If you expect to open this up as a public service, use POST.
I am already using the standard WebAPI and returning JSON objects to my client. Now I saw an application that returned OData.
Can someone explain if there is any reason for me to use OData if I do not want to query my data from anything other than my own client running in the browser. Are there advantages that I could get through using OData ?
If you are only using your data in your own browser application, there is only few advantages to use OData in your situation:
OData is able to provide metadata about your service interface that can be used to generate client code to access the service. So if you have lots of client classes that you need to create, this could speed up your process. On the other hand, if you can share your classes between the server and an ASP.NET based client or if you only have a few classes, this might not be relevant in your situation.
Another - bigger - advantage in your situation is the support for generic queries against the service data. OData supports IQueryable so that you can decide on the client side on how to filter the data that the service provides. So you do not have to implement various actions or use query parameters to provide filtered data. This also means that if you need a new filter for your client, it is very likely that you do not have to change the server and can just put up the query on the client side. Possible filters include $filter expressions to filter the data, but also operations like $skip and $top that are useful when paging data. For details on OData and queries, see this link.
For a complete overview about OData and Web API see this link.
Here are few advantages of OData.
OData is a open protocol started by Microsoft is based on Rest Services so we can get data base on URL.
It suppport various protocol like http,atom,pub and also support JSON format.
No need to create proxy classes which we used to do it in web service.
You will able to write your own custom methods.
It is very light weight so the interaction between client and server will be fast compared to web service and other technologies.
Very simple to use.
Here are few reference links.
http://sandippatilprogrammer.wordpress.com/2013/12/03/what-is-odata-advantages-and-disadvantages/
http://geekswithblogs.net/venknar/archive/2010/07/08/introduction-odata.aspx
http://www.zdnet.com/blog/microsoft/why-microsofts-open-data-protocol-matters/12700
I agree with the answers already posted, but as an additional insight...
You mentioned that:
... if I do not want to query my data from anything other than my own
client running in the browser...
You may not wish to run it normally through anything but your own cilent, but using oData you could use other querying tools for debugging. For example LinqPad allows you to use oData endpoints (such as that provided by stackoverflow).
It's probably not a good enough reason to implement oData if you don't have another reason to do so, but it's an added bonus.