I am exposing some Pages in Navision 2009 as web services. To update a record, you have to issue a Read request, and send the Key field along with your Update request.
I would rather calculate the Key myself for 2 reasons:
Using the filters in the read request is awkward - a sql query would fit on one line.
Performance is terrible.
I've been able to figure out that at least part of the key is a Base64 encoded string of the columns that make up the primary key. I hope that someone can tell me where to look (database, code base, docs, etc) to tell me how the Key is calculated.
Sorry, I don't know how to calculate the key. Instead of calculating the key, have you considered doing your data manipulation in a codeunit instead, and exposing that codeunit as a webservice?
Related
I have a get request that will give me a winner based on a list of inputs.
eg). [{rabbit:3, tiger:2}, {rabbit:1, donkey:3}, {bird:2}]. // the winner is {rabbit:1, donkey:3}
I would like to design a get end point that will take a list.
One way I could think of is like this:
/GET
winner?rabbit,3?tiger,2&rabbit,1?donkey,3
A request param map would like like key:{rabbit,3?tiger,2}: value=[]
alternatively, I could do:
/GET
winner?id1=rabbit,3?tiger,2&id2=rabbit,1?donkey,3
but I don't need the id information at all.
While this serves the purpose for what I need, I am wondering what would be the best way to represent query param with sub-object?
There really isn't a great answer here.
As far as HTTP is concerned, any spelling that is consistent with the production rules described by RFC 3986 is fine.
If you have a representation that is easily described by a URI Template, then you (and your clients) can take advantage of the general purpose template libraries.
BUT... templates are not so flexible that they can be used to describe arbitrary message schemas. We've got support for strings, and lists (of strings) and associative arrays (of strings), and... that's pretty much it.
On the web, we might handle an arbitrary case using a form with a textarea control that accepts a string representation of the message; the browser would then create a key value pair, where the value is an encoded representation of the information in the text area.
So, for example, you could copy a string representation of a JSON document into the form, submit the form, and the browser would compose the matching query-part. On the server, you would reverse the process to get at the JSON document.
There's nothing particularly magic about using a key value pair, of course. Another possibility would be to ignore the key of the key value, and just use the properly encoded value as the query. Again, the server just reverses the process.
Another somewhat common attempt is to use key value pairs, treating the keys as "paths" - which is to say each key identifies a location in the original document, and the value indicates the information available at that location.
?/0/rabbit=1&/0/tiger=2&/1/rabbit=1&/1/donkey=3&/2/bird=2
In this example, the schema of the keys is based on JSON Pointer (RFC 6901), which is possible way to flatten hierarchical data into key value pairs. Which may not be "best", but is at least leaning in the direction of readily standardizable. (A standardized form would be an improvement, but I wasn't able to identify one).
The most obvious seems:
GET /winner?rabbit=3&tiger=2&rabbit=1&donkey=3
I have a REST syntaxe question:
what url do you give to an endpoint to extract data similar to the record which from the id passed?
By exemple : I have a class Record:
Record {id:12, phoneNumber:"+336746563"}
I want a endpoint who will return all the records who share the same phoneNumber than the record with the id 12
which url respect the most the REST protocol ?
EDIT IMPORTANT : the client DON't know the phone number when he call the url. only the 12 id.
what url do you give to an endpoint to extract data similar to the record which from the id passed?
Anything you want -- the machines don't care what spelling you use for your resource identifiers.
I want a endpoint who will return all the records who share the same phoneNumber than the record with the id 12
/all-records-with-same-phone-number-as?id=12
/all-records-with-same-phone-number-as?12
/all-records-with-same-phone-number-as/12
All of these examples are fine. They have different trade offs -- the first one is really easy to generate using an HTML form. The last once allows you do interesting things with relative references and dot-segments.
/record/12/all-records-with-same-phone-number
similar to the above, we've just juggled the order of the path segments a little bit. Might be useful if we want to have relative references to other resources under the same /record/12 stem.
If you are expecting to need to paginate, then you might want to think about how the paging parameters fit with everything else. Again, the machines don't care, but some spellings are easier to work with than others.
I am not sure if I understand the question but let me try.
You can do this in various ways which is best suited for you w.r.t. your programming language. For example, domain.com/api/records/123456 can be the end-point. 123456 is a parameter and your code will return all the records having phoneNumber=123456.
Alternatively, the end-point can be domain.com/api/records?phoneNumber=12345.
Or Even, domain.com/api/records/123456/phonenumber.
The other option is to have the request data in the body and the domain would just look like domain.com/api/records with request as {"PhoneNumber":"123456"}
AFAIK, all these URLs respect REST protocol.
I would use something like
/service/records/{id}/similar
where the service would define similarity. It depends on the usecases for when Record becomes more complex and the client should able to specify fields.
This would sooner or later result in queries that would not be based on an existing record and my look like
/service/records?foo=1&bar=2
I could also think of
/service/records/phone-number/12345
because you are really interested in records with the same phoneNumber, not similarity?
But again, as things get more complex you will be better off with a query I think.
My understanding of REST is that anything that does not change state to the underlying system (e.g. query) should be a GET request. This also means that query parameters have to be put into the URI like so:
api/SomeMethod/Parameter1/{P1:double}/Parameter2/{P1:double}
or as query strings as discussed here:
REST API Best practice: How to accept list of parameter values as input
Sometimes the query may require a lengthy vector (number of x/y points). How do I overcome the length problem of URIs here? Should I just use a POST? Thanks.
If the vector really is big enough to start worrying about you should really consider moving it out of the query params and represent it as a RESTful resource.
For example, create a collection at:
api/Vector
Then your API clients can POST their large vectors and then in another request refer to it by a single id number.
This reduces the size of the query length drastically, abides by REST, and allows for these vectors to be easily reused. If you are worried about storage you can expire vectors after 30 minutes or longer.
Another option is to go down the JSON-LD road which is similar except you don‘t host the vectors. You just provide an #context object and API clients will host the vector on their own server and reference it to your API by URL in a query parameter.
I have already gone through this
How best to design a REST API with multiple filters?
This does help when you have say 3 or 4 filtering criteria and you can accomodate that in the query String.
However let's take this example
You want to get call details about 20 telephone numbers, between a certain startdate and enddate.
Now I do agree ideally one should be advised to make individual queries for each number and then on the client side collate all data.
However for certain Live systems that would mean 20 rounds of queries on the switches or cdr databases. That is 20 request-response cycles plus the client having to collate and order them again based on time. While in the database level it would have been a simple single query that can return an ordered data and transformed back into a REST xml response that the client can embed on their system.
If we are to use GET the query string will get really confusing and has a limit as well.
Any suggestions to get around this issue.
Of course we can send a POST request with an xml having all numbers in it but that is against REST Get principles.
In case of GET use OData queries. For example when your start and end dates represented as numbers (unix time) URI could look like:
GET http://operatorcalls.com/Calls/Details?$filter=Date le 1342699200 and Date gt 1342526400
What you seem to be missing is an important concept of REST, caching. This can be done, as an example, in the browser, for a single client. Or it can be done as a shared cache between all the clients and the live production system (whatever it may be). Thus reducing queries against a live production system, or in your example, actual switches.
You should really take some time to read Fieldings thesis, and understand that REST is an architectural style.
I found a solution here Handling multiple parameters in a URI (RESTfully) in Java
but not quite happy with it.
So in effect we will end up using /cdr?numbers=number1,number2,number3 ...
However not too pleased with it as there is a limit to Query String in the url and also doesn't really seem to be an elegant solution. Anyone found any solution to this in their own implementation?
Basically not using POST for this kind of Fetch requests and also not using cumbresome and lengthy Query Strings.
We are using Jersey but also open to using CXF or Spring REST
I'm building a a rest service which uses memcached.
support my service handles:
GET http://server/books/6/pages?top=10&skip=5&sort=number
is it better to use the url as a memcached key? or should I build my own key string by concatenating the arguments in some way? e.g. "books_6_10_5_number". or maybe key can be a json representation of the arguments?
using the url is very easy. however if someone swaps the order of arguments there will be a cache miss.
the same question is also relevant for sql queries - should I store the sql as key or break it down to its arguments.
EDIT: as suggested, sorting would work for urls (though not for sqls). the question is more general: are there any other trade-offs in using the raw format (url, sql) vs. rolling my own format ("books_6_10_5_number")