I notice quite a lot of entities returned by the API only include URLs to
their relationships rather than nested objects.
Was this a conscious design decision? I understand some of the benefits of
resource discoverability and identifying objects by their URL rather than
their ID, but I’m wondering if this is just a recipe for horribly
inefficient client apps and increased load on your servers.
Example: I want to display a list of timeslips. Next to each timeslip I
want to display: The date, the hours, the project name, the user name and
the task description.
To do this, I need to:
- Make a GET request to get a list of timeslips
- For each timeslip in the response that I want to display, I then have to:
- Fetch each User from the server
- Fetch each Project from the server
- Fetch each Task from the server
If I get back 20 timeslips in my original request, I find myself having to
make up to potentially 61 HTTP requests just to display one screen of
information. Yes, I could do some kind of smart conditional fetching
depending on whether I’ve fetched a particular URL already but we’re still
talking n+1 requests.
Shouldn’t I just need to make one request for this information? If the
original GET returned some nested objects for project/user/task this would
make life much easier.
Am I missing something obvious here?
Hi Luke,
The simple answer here is that the API is not set in stone and it is
certainly possible to add nested resources where necessary and where we can
maintain backwards compatibility. The conscious design decision was to get
the API out the door and into our developers’ hands and optimise it
according to what developers actually need. We’ve already added some
nested resources in response to feedback to speed up developers’ apps. I
suggest you send me an email privately with the specifics of the problem
you’re trying to solve and we’ll work together to speed up your app.
While you could structure your app the way you outline above, you
could instead fetch the list of timeslips, fetch the list of users, fetch
the list of projects and fetch the list of tasks - that’s 4 API calls not
61.
Cheers,
GraemeOn 1 April 2012 19:33, Luke Redpath luke@lukeredpath.co.uk wrote:
I notice quite a lot of entities returned by the API only include URLs to
their relationships rather than nested objects.
Was this a conscious design decision? I understand some of the benefits of
resource discoverability and identifying objects by their URL rather than
their ID, but I’m wondering if this is just a recipe for horribly
inefficient client apps and increased load on your servers.
Example: I want to display a list of timeslips. Next to each timeslip I
want to display: The date, the hours, the project name, the user name and
the task description.
To do this, I need to:
- Make a GET request to get a list of timeslips
- For each timeslip in the response that I want to display, I then have to:
- Fetch each User from the server
- Fetch each Project from the server
- Fetch each Task from the server
If I get back 20 timeslips in my original request, I find myself having to
make up to potentially 61 HTTP requests just to display one screen of
information. Yes, I could do some kind of smart conditional fetching
depending on whether I’ve fetched a particular URL already but we’re still
talking n+1 requests.
Shouldn’t I just need to make one request for this information? If the
original GET returned some nested objects for project/user/task this would
make life much easier.
Am I missing something obvious here?
–
You received this message because you are subscribed to the Google Groups
“FreeAgent API” group.
To view this discussion on the web visit
https://groups.google.com/d/msg/freeagent_api/-/Iu4vT6XNuxIJ.
To post to this group, send email to freeagent_api@googlegroups.com.
To unsubscribe from this group, send email to
freeagent_api+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/freeagent_api?hl=en.
Graeme Boyd
Senior Software Engineer
FreeAgent Central Ltd
40 Torphichen Street, Edinburgh EH3 8JB
Registered in Scotland SC316774
I notice quite a lot of entities returned by the API only include URLs to
their relationships rather than nested objects.
Was this a conscious design decision? I understand some of the benefits of
resource discoverability and identifying objects by their URL rather than
their ID, but I’m wondering if this is just a recipe for horribly
inefficient client apps and increased load on your servers.
Example: I want to display a list of timeslips. Next to each timeslip I
want to display: The date, the hours, the project name, the user name and
the task description.
To do this, I need to:
-
Make a GET request to get a list of timeslips
-
For each timeslip in the response that I want to display, I then have to:
-
Fetch each User from the server
-
Fetch each Project from the server
-
Fetch each Task from the server
If I get back 20 timeslips in my original request, I find myself having to
make up to potentially 61 HTTP requests just to display one screen of
information. Yes, I could do some kind of smart conditional fetching
depending on whether I’ve fetched a particular URL already but we’re still
talking n+1 requests.
Shouldn’t I just need to make one request for this information? If the
original GET returned some nested objects for project/user/task this would
make life much easier.
Am I missing something obvious here?
Perhaps a backwards-compatible enhancement would be to allow the client to
specify which related objects they need in the response, e.g.:
GET /timeslips?include=user,project,task
or
GET /timeslips?include=user&include=project&include=task
Hi Graeme
I don’t mind keeping this public.
At the moment, my main requirement is timeslips, as outlined above.
Good point about fetching all projects, users and tasks up front. This is
certainly much better but still not optimal.
I guess I was also trying to get a discussion going on why this approach
was taken. If it was just to get the API out of the door quickly then fair
enough. Going forward, I’d love to see some flexibility, perhaps along the
lines of what I mentioned above, where you can specify which nested
resources are required in the response (up to one level deep would be more
than sufficient for most cases I think).On Monday, April 2, 2012 10:47:13 AM UTC+1, Graeme Boyd wrote:
Hi Luke,
The simple answer here is that the API is not set in stone and it is
certainly possible to add nested resources where necessary and where we can
maintain backwards compatibility. The conscious design decision was to get
the API out the door and into our developers’ hands and optimise it
according to what developers actually need. We’ve already added some
nested resources in response to feedback to speed up developers’ apps. I
suggest you send me an email privately with the specifics of the problem
you’re trying to solve and we’ll work together to speed up your app.
Also, there doesn’t seem to be a way of fetching all tasks. For some reason
/tasks returns a 404. Does the project=:project query have to be required?
Either way I would have expected a 400 instead of a 404 if thats the case.
Its also not clear from the docs, but does the API only return timeslips
for the current user?
I also have some concerns about permissions. If a user only has timeslips
permissions, then they won’t have the permissions necessary for me to fetch
the projects or users (with the latter requiring quite high permission
levels), meaning I could never fetch complete data about a timeslip.
Hi,
I’m truing to attach images to expenses and always receive a 404
(Resource not found) response.
I tried to send the attachment info with both create and update calls
(post,put) but with no luck.
When I try to update the expense itself I have no problems so it must be
something else.
I have no problem sending attachments to v1 of the API.
I really can’t figure out what is wrong.
Regards,
Hristo