Examples of GraphRepository keywords - spring-data

Is there a location or resource of triggers for method names of a GraphRepository? I know you can do XYZById Or XYZByNameAndId, but is there any resource for what these are capable of? I would like to do something like XYZByIdBetween(int start, int end) but this does not work for Spring-data 2.1.0-RELEASE currently.

You can take a look at the following URL in the official spring data documentation the explains how you can format your method names.

Related

Filter by method attribute in Doxygen

I am new to Doxygen but I want to use it for a technical documentation for our team.
The background: We have several services in .NET which are going to be called from a JAVA backend through RPC.
Therefore it is quite useful to have those services documented for the JAVA guys.
Using the Doxywizard did help in the first place, but it created a huge overflow of data, which I want to filter, but have no clue how to.
What I want to achieve is, that Doxygen ONLY will use methods, which does have a specific attribute.
For example:
[RpcMethod(id: "GetNumDemo", description: "A demo method")]
public async Task<int> GetNumDemo(JavaDTO dtoObject, int randNum)
I want to have the method within the documentation found by Doxygen since it has the RpcMethod attribute and also cause it have a JavaDTO object, I want to have this class documented as well.
But I am overwhelmed with it ... do you guys can help me? ... at least with a hint within the Doxygen documentation.
Read through the documentation and goodled

What is the best practice to design the rest api url if one resource identifier is a path

It is straightforward to put resource id into url if it is a int or long type. e.g.
GET files/123
But my problem is that my resource identifier is a path. e.g. /folder_1/folder_2/a.sh because the underlying implementation is a filesystem. So I can not put it as part of rest api url because it is conflict with url path.
Here's approaches what I can think of:
Put the path id as the request param. e.g.
GET files?path=/folder_1/folder_2/a.sh
Encode/decode the path to make it qualifier as part of url.
Introduce another int/long id for this resource in backend. And map it to the path. The int/long type resource id is stored in database. And I need to maintain the mapping for each CURD operation.
I am not sure whether approach 1 is restful, approach 2 needs extra encoding/decoding, and approach 3 needs extra work to maintain the mapping.
I wonder what is the best practice to design the rest api url for this kind of case.
Simple:
#GET
#Path("/files/{path:.+}")
#Produces({MediaType.TEXT_PLAIN})
public String files(
#PathParam("path") String path
) {
return path;
}
When you query files/test1/tes2 via url output is:
test1/tes2
Just put the path after a prefix, for example:
GET /files/folder_1/folder_2/a.sh
There isn't a conflict, since when the request path starts with your known prefix (/files/, in the above example), you know that the rest should be parsed as the path to the file, including any slashes.
Well, my experience designing "restful" APIs shows that you have to take into consideration future extensions of your API.
So, the guidelines work best when followed closely when it makes sense.
In your specific example, the path of the file is more of an attribute of the file, that can also serve as its unique ID.
From your API client's perspective, /files/123 would make perfect sense, but /files/dir1/file2.txt is debatable.
A query parameter here would probably help more, much like what you would do if you wanted to retrieve a filtered list of files, rather than the whole collection.
On the other hand, using a query parameter would also help for future extensions, since supporting /files/{path} would also mean conflicts when attempting to add sub-resources to your files endpoint.
For example, let's assume that you might need in the future another endpoint /files/attributes. But, having such an endpoint, would exclude any possibility for your clients to match a file named attributes.

Defining an array in play's config file

I didn't find any information about that topic. Is there any way to define an array in the standard play config file app.config which have such the values as?
application.secret="Gk<9kCgMu#A62eyfcJ;YZ2nFnA;4324/gfdg]afdsfds"
application.langs="en"
application.global=common.Global
Yes, it is possible and described in the Play configuration chapter.
In general, what you are looking for is this:
my.setting="[value1,value2,value3]"
In your code you can access it like this:
Play.current.configuration.getStringList("my.setting") //returns an Option[java.util.List[String]]
You may also use getLongList, getBooleanList and so on.
I find this answer searching for "play framework config array".
For Play 2.7 the correct syntax for a List is:
my.setting=["value1","value2","value3"]
otherwise you get an Exception like
com.typesafe.config.ConfigException$WrongType: application.conf # file:/xxxxx/application.conf: 12: my.setting has type STRING rather than LIST
Hope this helps someone else.

grave in the Go Language

After looking around for a while I was able to understand how the json: tags are used in the Go language. However two tags I have come across I'm still lost on, and can't seem to find documentation on it.
Both pertain to a REST api service and the full code can be found here-> code.google.com
What is the root: tag used for
gorest.RestService `root:"/orders-service/" consumes:"application/json" produces:"application/json"`
as well how does the method: tag work?
userDetails gorest.EndPoint `method:"GET" path:"/users/{Id:int}" output:"User"`
I didn't know if anyone had any links to a site or document that might explain this more, from the examples I can learn enough to use it. However, I would really like to fully understand it.
Thanks for your time!
Tags are nothing but strings, they don't have any meaning per-se.
Libraries can use reflection to introspect struct fields and interpret their tags. See reflect.StructTag.
In your case, gorest parses the following tags on Services:
root
consumes
produces
and these on Endpoints:
realm
method
path
output
input
role
postdata
Their meaning is described in gorest's documentation.
These are gorest tags. See gorest wiki http://code.google.com/p/gorest/wiki/GettingStarted

Managing API endpoints as constants

I've inherited an iPhone app that has a file containing all code necessary to perform API calls to our server (ServerRequests.h/m).
All endpoints for the API are buried within the various methods, and I'm looking for a way to refactor these endpoints out into their own separate file, or at the very least declared constants at the top of this file.
The problem is portions of the API endpoints are variable, such as user_id, photo_id, etc.
Am I amble to store a format string as constant and then have the variable portions replaced at a later time?
If not, do you have any suggestions about how to manage my API endpoints in a better way than just strewing them all throughout a file?
Thanks!
If I understand your need, something like this might work for you:
#define SOME_ENDPOINT #"what/ever/%#/you/need"
At the point of use, you use string formatting to get the final string:
[NSString stringWithFormat:SOME_ENDPOINT, user_id, ...];
IOW the majority of the string is stored in a constant that is a template used as the format spec for formatting the final string.
Is that what you want? Or need something 'fancier'? There is a feature of Python that I miss in Obj-C - you can have 'named' specifiers in the format like #"some/%(user_id)s/etc/etc/" and when you perform the formatting, you supply a dict(ionary). The 'user_id' spec is used as a key to find the associated value, which is then formatted (e.g., using the 's' spec in my example. Have not found a similar feature in Obj-C tho.