I am using servlets to allow clients to do CRUD Operations on a list. However I have one servlet, but it's possible to have multiple URL's get to this servlet because I have a wildcard character in the URL-Pattern.
http://localhost:8080/WebServiceDesignStyles3ProjectServer/SpyListCollection
This is the generic way to send a request to the servlet. However, for certain operations
http://localhost:8080/WebServiceDesignStyles3ProjectServer/SpyListCollection/{name}
Is a valid way to send a request to the servlet. I need to be able to get the last portion of that URL. It was told that I should be using getHeader("Accept") to be retrieving that. I've had success using getRequestURI(), but I was hoping someone could provide an example using getHeader(). Or at least an explanation describing the differences of the two.
Thank you for your time,
Kirie
You could split the request path by the separator(/) and check the last part.
String reqURI = req.getRequestURI();
String[] parts = reqURI.split("/");
if (parts[parts.length - 1].equals("SpyListCollection") {
//Generic operation
} else {
String operation = parts[parts.length - 1];
}
Related
I am trying to make a get request to retrieve a string
When I use
retrieve : Task.Task Http.Error String
retrieve = getString "http://api.endpoint.com"
everything works fine.
On the other hand if I use
retrieve : Task.Task Http.Error String
retrieve = get Json.Decode.string "http://api.endpoint.com"
the http request gets done, but the chained tasks are not executed.
My question is: what is the difference between the two approaches above? Am I doing something wrong with the second one? How to debug it?
getString returns the response of the get request as a String. get take a JSON decoder and runs that over the response of the get request. So if you provide Json.Decode.string, it will expect the response to be have a Json encoded string in it. So it expects extra double quotes in the response.
If your http request fails the best way to debug is to look at what kind of error you get. In this case you'll probably get an UnexpectedPayload because the request succeeds, but the decoder fails.
When leveraging a Web Api endpoint hosted on a different server, what is the best way to have pagination to avoid excessive serialization and deserialization while still being able to see the total # of matches that were found in the Get request?
Web Api:
[Queryable]
public IQueryable<Customer> Get(string input) {
return _repo.GetCustomers(input).AsQueryable();
}
Controller Code:
HttpResponseMessage response = client.GetAsync("api/customer?input=test&$top=2&$skip=0").Result; // test string
if (response.IsSuccessStatusCode) {
CustomerSearchResultViewModel resultViewModel = new CustomerSearchResultViewModel();
resultViewModel.Customers = response.Content.ReadAsAsync<IEnumerable<Customer>>().Result.ToList();
resultViewModel.TotalResults = resultViewModel.Customers.Count;
}
In this example, the TotalResults will be capped at 2 rather than returning the total # of matches found before pagination.
Is there a way to get the total results out by leveraging OData? If that is not possible, how can I best preserve OData functionality while getting out the number I need?
You can use the OData $inlinecount option. The request would look like,
api/customer?input=test&$top=2&$skip=0&$inlinecount=allpages.
Now, we don't support sending the value of count with the default json and xml formatters out-of-the-box. Your client code is the best example why we have decided not to send it by default. The reason is that the client wouldn't know what to do with the extra count property. Our OData formatter supports $inlinecount option by default as the OData format has clear rules for where the count value fits in the response.
That said, you can do a simple change to support count in your responses. Your client code also has to change though. Refer to this answer for details.
I am creating a HTTPS connection and setting the request property as GET:
_httpsConnection = (HttpsConnection) Connector.open(URL, Connector.READ_WRITE);
_httpsConnection.setRequestMethod(HttpsConnection.GET);
But how do I send the GET parameters?
Do I set the request property like this:
_httpsConnection.setRequestProperty("method", "session.getToken");
_httpsConnection.setRequestProperty("developerKey", "value");
_httpsConnection.setRequestProperty("clientID", "value");
or do I have to write to the output stream of the connection?
or do I need to send the Parameter/Values by appending it to the url?
Calling Connection.setRequestProperty() will set the request header, which probably isn't what you want to do in this case (if you ask me I think calling it setRequestHeader would have been a better choice). Some proxies may strip off or rewrite the name of non-standard headers, so you're better off sticking to the convention of passing data in the GET URL via URL parameters.
The best way to do this on a BlackBerry is to use the URLEncodedPostData class to properly encode your URL parameters:
URLEncodedPostData data = new URLEncodedPostData("UTF-8", false);
data.append("method", "session.getToken");
data.append("developerKey", "value");
data.append("clientID", "value");
url = url + "?" + data.toString();
HTTP GET send data parameters as key/value pairs encoded within URL, just like:
GET /example.html // without parameters
GET /example.html?Id= 1 // with one basic parameter
GET /example.html?Id=1&Name=John%20Doo // with two parameters, second encoded
Note follow rules for character separators:
? - split URL in two pieces: adddress to left and paremeters to right
& - must be used to separate on parameter from another
You must know your platform specific native string encode function. Javascript uses escape, C# uses HttpUtility.UrlEncode
Yep, headers and properties are pretty much all you can send in a GET. Also, you're limited to a certain number of characters, which is browser dependent - I seem to recall about 1024 or 2000, typically.
To show this fundamental issue in .NET and the reason for this question, I have written a simple test web service with one method (EditString), and a consumer console app that calls it.
They are both standard web service/console applications created via File/New Project, etc., so I won't list the whole code - just the methods in question:
Web method:
[WebMethod]
public string EditString(string s, bool useSpecial)
{
return s + (useSpecial ? ((char)19).ToString() : "");
}
[You can see it simply returns the string s if useSpecial is false. If useSpecial is true, it returns s + char 19.]
Console app:
TestService.Service1 service = new SCTestConsumer.TestService.Service1();
string response1 = service.EditString("hello", false);
Console.WriteLine(response1);
string response2 = service.EditString("hello", true); // fails!
Console.WriteLine(response2);
[The second response fails, because the method returns hello + a special character (ascii code 19 for argument's sake).]
The error is:
There is an error in XML document (1, 287)
Inner exception: "'', hexadecimal value 0x13, is an invalid character. Line 1, position 287."
A few points worth mentioning:
The web method itself WORKS FINE when browsing directly to the ASMX file (e.g. http://localhost:2065/service1.asmx), and running the method through this (with the same parameters as in the console application) - i.e. displays XML with the string hello + char 19.
Checking the serialized XML in other ways shows the special character is being encoded properly (the SERVER SIDE seems to be ok which is GOOD)
So it seems the CLIENT SIDE has the issue - i.e. the .NET generated proxy class code doesn't handle special characters
This is part of a bigger project where objects are passed in and out of the web methods - that contain string attributes - these are what need to work properly. i.e. we're de/serializing classes.
Any suggestions for a workaround and how to implement it?
Or have I completely missed something really obvious!!?
PS. I've not had much luck with getting it to use CDATA tags (does .NET support these out of the box?).
You will need to use byte[] instead of strings.
I am thinking of some options that may help you. You can take the route using html entities instead of char(19). or as you said you may want to use CDATA.
To come up with a clean solution, you may not want to put the whole thing in CDATA. I am not sure why you think it may not be supported in .NET. Are you saying this in the context of serialization?
I am doing an e-commerce solution in ASP.NET which uses PayPal's Website Payments Standard service. Together with that I use a service they offer (Payment Data Transfer) that sends you back order information after a user has completed a payment. The final thing I need to do is to parse the POST request from them and persist the info in it. The HTTP request's content is in this form :
SUCCESS
first_name=Jane+Doe
last_name=Smith
payment_status=Completed
payer_email=janedoesmith%40hotmail.com
payment_gross=3.99
mc_currency=USD
custom=For+the+purchase+of+the+rare+book+Green+Eggs+%26+Ham
Basically I want to parse this information and do something meaningful, like send it through e-mail or save it in DB. My question is what is the right approach to do parsing raw HTTP data in ASP.NET, not how the parsing itself is done.
Something like this placed in your onload event.
if (Request.RequestType == "POST")
{
using (StreamReader sr = new StreamReader(Request.InputStream))
{
if (sr.ReadLine() == "SUCCESS")
{
/* Do your parsing here */
}
}
}
Mind you that they might want some special sort of response to (ie; not your full webpage), so you might do something like this after you're done parsing.
Response.Clear();
Response.ContentType = "text/plain";
Response.Write("Thanks!");
Response.End();
Update: this should be done in a Generic Handler (.ashx) file in order to avoid a great deal of overhead from the page model. Check out this article for more information about .ashx files
Use an IHttpHandler and avoid the Page model overhead (which you don't need), but use Request.Form to get the values so you don't have to parse name value pairs yourself. Just pretend you're in PHP or Classic ASP (or ASP.NET MVC, for that matter). ;)
I'd strongly recommend saving each request to some file.
This way, you can always go back to the actual contents of it later. You can thank me later, when you find that hostile-endian, koi-8 encoded, [...], whatever it was that stumped your parser...
Well if the incoming data is in a standard form encoded POST format, then using the Request.Form array will give you all the data in a nice to handle manner.
If not then I can't see any way other than using Request.InputStream.
If I'm reading your question right, I think you're looking for the InputStream property on the Request object. Keep in mind that this is a firehose stream, so you can't reset it.