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.
Related
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 :)
Currently working on an ajax call to an ASP web service (.asmx).
In a situation where I POST to the url/.asmx/WebMethod, am I exposing information of any kind?
In the 'WebMethod' I am running a PostJsonAsync that calls an API and passes along a json string.
As I am still learning, I've been told that calling any public [WebMethod] exposes the code, but I am not sure how that is possible.
Is it possible at all for a user to access the WebMethod server-side code that I have and peek into the API calls that are available?
I've attempted some minor security methods.. We are working with Sitefinity CMS. What I did was call a WebMethod that receives the CurrentUserIdentity and returns a GUID. If the current user is logged in, it returns a valid Guid, if not it returns a Guid full of zeros.
Then, I call the WebMethod containing my API call and post a json object along with the valid or invalid GUID. The server-side WebMethod code will then verify if the GUID is valid and continues based on if a UserProfile can be generated.
To me, this seems to be secure, but I've been told that this still leaves the WebMethod exposed as well as the API. I am however just not understanding what is exposed and what can be used.
If anybody can direct me to any resources that has more information on this, or if anybody can advise me on WebService security, I would appreciate it.
Thanks in advance.
If you're calling the methods via AJAX, then they are exposed to the public...and can be called by anything that can make a call to your server. That being said, there's nothing wrong with it unless you're doing something that's easily abused.
In your particular case, it sounds like the code is accepting a GUID that is assumed to have come from the first API call. If that's really the case, you may want to rethink how the mechanism works. Adding authentication checks for each method that needs to be restricted may be a better solution.
I am new to ASP.NET Web API and I found that it has one limitation which is very annoying. It only supports one parameter to post method. (Read more here: Using jQuery to POST [FromBody] parameters to Web API)
From that link, it seems like they design it this way. It doesn't make any sense to me to have such strange limitation.
If anyone knows why it was designed this way, please let me know.
This is the way HTTP works. An HTTP POST sends a body. And as a web api, that body represents the resource object that is being POSTed.
That 'object' which is in the POST can be a complex object with many properties so you can create a wrapper object to represent the resource. It can also be an array of objects as a collection of resources.
As a side note, if you're designing a RESTful web api, then it's desirable to POST an single resource or array of resources (objects) to an endpoint that represents a collection of resources. For example, I post a student to /api/students and it adds that student.
You can have many parameters but you can only have one [FromBody], and that's because an HTTP message can only have one body. You can map as many parameters as you like to parameters on the query string.
I have a public web app that calls ASP.NET web method in an ASMX file, located in the same site folder in IIS. But, to prevent bots to ping the service directly, we'd like to secure the API so that only our HTML 5 client page can access it. Do you have a suggestion on how should I implement this kind of thing ? Not too much, just a simple mechanism that won't take a week of testing please. Doesn't have to be a 100% full proof method since it is public data and the API just pumps data out, not inserting anything. Just something to limit possibilities of DDOS attack on the API.
The way I've tackled this in the past is with a custom header.
Essentially if your web page is using some form of AJAX call to call back to your services layer, then you can use something like:
xhr.setRequestHeader('custom-header', 'value');
where 'xhr' is an XML Http request that you've built in Javascript
of course you could also take the much easier route of just adding a parameter to your calls query string, EG:
in your ajax call, request:
http://my.services/service.asmx?somesecretkey=foobar
instead of just
http://my.services/service.asmx
Then you can just use the request's query string collection server side to see if it's present or not, and refuse the connection if it's not.
You could even go so far as providing some seed value in the data passed to the page in the first place, then use that seed value to create a unique value (one the server can also calculate) that is returned back in your request to the server.
Doing it that way would provide a slightly higher level of security, as the values would be semi random and not easy for a bot to guess.
Bear in mind also, that if you control the calling page, and you are doing this by ajax, you can also put this key in your post variables collection too so it doesn't have to be visible in the get request.
I am just wondering how to do this:
I have a page which shows some tabular data. On each row there is a checkbox. The user selects two/more checkboxes; my web page must find the corresponding ids of the rows which are checked. I must send this to the http web service. (basically a *.ashx file). I have two questions:
how will I access this on web server
how will my web server know the total no. of items I've passed. Must I manually send this to the server as a http post parameter?
what if the data I am sending is more complex like a person object which has fields like FirstName, LastName, etc. ?
I know I can use a asp.net web service or a wcf service with exposes a datacontract. But what is the best way to handle this without the SOAP overhead; what if you are sending all this data via ajax as a normal http post?
http://jquery.malsup.com/form/#getting-started might be worth investigating as a starting point.
In terms of your questions, the answers will partly depend on whether you are using MVC or WebForms. But in general:
If you use the above plugin, you will access it just like it was a normal form submit (post).
They will be populated into Request.Form.
This shouldn't be a problem. Model binding on MVC should handle this fine, I am not 100% sure of the equivalent on WebForms (you could always do it manually).
My suggestion would be to ignore the AJAX requirement for now. Get it working with a standard form submit (POST). Then come back and integrate the above plugin to enable AJAX.
1. How will I access this on web server
Using either postback (and a checkboxlist control), or handling POST yourself. GET wouldn't be appropriate for the task.
2. How will my web server know the total no. of items I've passed. Must I manually send this to the server as a http post parameter?
It will send back the value of each checkbox you have on the form, which will give you the total.
3. What if the data I am sending is more complex like a person object which has fields like FirstName, LastName, etc. ?
You could use Viewstate for this, or just re-assemble the objects on the server. Typically this means putting an ID in the checkbox value for the person each checkbox represents - you don't need to send back every piece of information about the object.
What is the best way to handle this without the SOAP overhead; what if you are sending all this data via ajax as a normal http post?
jQuery and JSON would be the best solution for this, if you want side step the built in ASP.NET ajax controls. As suggested, jQuery is the simplest Javascript library for the client side part of the task - you'll need to use $.post