Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 4 years ago.
Improve this question
All,
I'm interested in the ability to retrieve a specific element within a FHIR resource using a single URL call. For example, suppose I'm interested in the gender of my patients. I would read the using the URL, without having to walk the XML node path every time. Right now, this functionality does not appear to exist. What do you think about the usefulness of this? Would like to get a sense of the community interest. Thanks.
-Jeff
For the default query mechanism, you can't bring anything back other than the full resource. (And don't even have a guarantee that the desired element will be present on all instances of the resource unless that element was part of your search criteria - in which case, why bother asking? :>). There's a new mechanism for defining custom queries. Refer to _query in the search/query section of the FHIR spec. However, it's not clear whether this will allow retrieval of anything other than full resource instances either.
This functionality does not exist at this time. It's on the wishlist, and we're trying to decide whether we can frame it in a sensible and safe fashion. The case you describe is relatively obvious, but many others aren't. And, in fact, when I think about it, it's not really clear to me how it works. what do you get back? just the gender element? so the server needs to - in effect - do the node walk for you, and you get, instead, to deal with a profusion of different schemas. It's not really obvious to me that this is a net saving for the client, and it's certainly a greater cost for the server.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 days ago.
Improve this question
I am creating several scheduled tasks within my Laravel site using the schedule() function within the Console/Kernel object. It acceptable to place simple logic in the schedule() function (based on the explanation from the Laravel site):
$schedule->call(function () {
DB::table('recent_users')->delete();
})->daily();
However, if the logic needs to be more complicated (100 lines of code or more to decide which models to focus on) basic programming rules instructs us to break the code up into additional functions and classes, which can be then be called by schedule(). However, I am a bit confused as to where these functions/classes go. A few possibilities:
A Controller function, even though it does not use a route?
A trait, used by the Kernel?
Console command, even though it's never called from the console?
A helper?
(edit) Other classes that share the Kernel's namespace?
Another kind of class that functions like a Controller, but internally only? (Something that I am not aware of.)
Where do these classes/functions go?
====
There are many established patterns can be regarded as correct or incorrect, based on Laravel's intended use, regardless of opinion. Also, there are many valid ways in which Laravel can be used. Within this context, there are many opinions on the best way to do things, many of which could be considered correct. That said, there are framework design patterns which are beyond the scrutiny of opinion (for now.) We use routes to link URLs to Controllers (not jobs.) We access models from the controllers and not the other way around. My question is intended to discover an established pattern that I am not aware of, and not to debate opinions regarding these patterns.
Basically, I want to avoid building my site in a way that with prove blatantly embarrassing in the future, (especially regarding lesser well known site elements, such as jobs, scheduling and console commands) simply because I did not know Laravel facts.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I'm trying to develop a REST API for the first time and it seems to me that I have a problem with realizing some basic REST API concepts. I'm not sure if I should only create CRUD operations for each model and then analize responses from these operations using Vue (in my case)? Or should I let my DRF side do some business logic?
SPECIFIC QUESTION
Here's an example. I want to remove an object and update some other objects in other table, which are related to the original object I would like to delete. Should I just create one POST(?) endpoint to do that or should I get those other objects I would like to delete using Vue, then call "delete" on each one of them from Vue, and only then delete the original object. As you can see in first case it's a complex operation and in the second case it's a couple of CRUD operations.
I'm asking this because I found many interpretations of REST API in Google and I struggle to find the truth. It seems to me that DRF doesn't want me to create complex views, looks like it just wants me to create 4 operations for each model.
Hope I made myself clear, thank you for trying to help.
What you really seem to be asking is what degree of coupling is appropriate for a REST API. The answer is as little as possible, but what's possible will depend on your application and your requirements.
To use your example, yes, it's preferable to have a uniform interface for deletion for each one of your resources, but what are your other requirements? Is it a problem if you cascade the deletion of children resources? Is it OK for you to automate deletion of orphan resources? Can you afford to lose transaction integrity by requiring the client to explicitly delete multiple resources through their own endpoints? If you can't find a way to make the uniform deletion interface work for you, there's nothing wrong or unRESTful in creating a single POST endpoint for doing what you need, as long as that's not coupled to the needs of a particular client implementation.
Don't expect to find "the truth", or a manual of best practices for REST API or final answers to your questions about that, because REST is just an architectural style, not a rigid specification for architectures. It's just a set of principles used to guide long-term design and evolution of applications.
If you don't have long-term requirements that ask for a careful adoption of REST principles, more important than finding the truth about REST is to respect the Principle of Least Astonishment, since many people already have strong opinions about how a REST API should be implemented. A good example is API versioning with URLs. Adding a version number to your URLs is a REST anti-pattern, but it's a widespread practice believed by many to be a REST best-practice. That happens because most so-called APIs are strongly coupled to the clients, and the API versioning makes it much easier to make backwards incompatible changes. Making backwards incompatible changes is not a problem when you implement REST API and clients correctly, but it takes a lot more work than simply tackling a version number somewhere.
If you really have long-term requirements or if you are genuinely interested in learning about how to design and implement a REST API correctly, try searching for "Hypermedia API" instead of "REST API". Many people gave up on the term REST and decided to start using a new term to refer to APIs that implement REST correctly.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
Are there any well known algorithms for figuring out the "Recommended Items" that websites often use? On a new project, I'm currently tracking things they've viewed, purchased, searched on, favourited, etc. I am curious what the best way would be to utilize all of this information to intelligently give meaningful recommendations.
I recommend you two books:
Programming Collective Intelligence
Toby Segaran (ISBN: 978-0-596-52932-1)
http://shop.oreilly.com/product/9780596529321.do
In this book, "Chapter 2. Making Recommendations" covers:
Collaborative Filtering
Collecting Preferences
Finding Similar Users
Recommending Items
etc..
Collective Intelligence in Action
Satnam Alag (ISBN: 1933988312)
http://www.manning.com/alag/
In this book, "Capter 12. Building a recommendation engine" covers:
Recommendation engine fundamentals
Content-based analysis
Collaborative filtering
I hope it helps you.
I thing easyrec would be a good starting point for you to track such user interactions.YOu just need to include some javascript code to your page and it does the rest.
http://easyrec.org/recommendation-engine
You can also check the other recommendation engines listed here
https://stackoverflow.com/questions/4469281/recommendation-engine#
but problem is most of these frameworks target user rating predicting over collaborative filtering.
There are mechanisms like 'people who bought this items also bought'.
Category tops: if someone is viewing 'computers/storage devices', show the top selling products in that category.
Previous searches: use the (non offensive) items that the user has browsed in previous sessions. (there is a way to track via cookie for non logged in users)
Promoted items: show items that are promoted and make big business benefit. However, do not get swayed away by this, show one or two promoted items to keep viewers interest.
There are recommendation engines, but as a developer business needs drives the recommendation creation. So, many times I find it's better to hack some SQL scripts to get them.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
I read about the Ajax API here Scraping/Parsing Google search results in Ruby
For some reason, I get completely different results from the same query when using the Ajax API than I do from normal search. Is there a simple explanation?
here are the two:
http://www.google.com/search?hl=en&rls=en&q=site%3Ahttp%3A%2F%2Ftwitter.com%2F+following&aq=f&oq=&aqi=0
http://ajax.googleapis.com/ajax/services/search/web?v=1.0&hl=en&rls=en&q=site%3Ahttp%3A%2F%2Ftwitter.com%2F+following&aq=f&oq=&aqi=0
both have parameters hl=en&rls=en&q=site%3Ahttp%3A%2F%2Ftwitter.com%2F+following&aq=f&oq=&aqi=0
run at the same time, they never give me the same results, often they're very different (depending on the search parameters.
what's going on?
Also, the
I'm guessing here, but usually if you do a google search using your regular account and have the history enabled, google will use your previous search to give you more accurate results. There are a bunch of things like that that may cause differences between searches with the exact same keyword(s)
The Axaj API is suspected to offer slightly different results to avoid the automatic harvesting of search result (SERP) info.
This is the same reason they only return 8 results per page and upto 8 pages via their AJAX api.
In principal they don't want people collecting this data, as it is usually used for SEO purposes in an attempt to coerce certain sites higher unduly.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
In a recent meeting with my client, we discovered we missed out on a Detail of User Story, that has already been implemented several iterations before.
The new requirement is not only an additional Feature but changed behaviour.
The original User Story goes like:
"Can View XYZ"
The new request however goes like:
"Can View XYZ but if B then XYZ must look like ABC"
Shall i consider this a Bug or a New User Story, or should i simply reopen the old user Story and edit it to account for the new request?
What is the "best-practice", what are pros and cons of each approach?
Well, since it is a new requirement, treat it as a new feature request. Definitely not a bug.
EDIT: Since it is not clear who missed the detail either you or the customer, you can take both ways. If you forgot about it, then it is your bug. If the customer forgot to tell about it, then it depends. If it is a little fix, you can reopen the old story. If it is much work to be done, make it a new one.
P.S. Does it really matter how you do it? The point is just implement it like the customer asks, regardless of your internal terminology.
(source: oracle-guy.com)
A Bug, a new User Story, reopening the old Story... is that really important? In any case, your customer is asking for a feature that is currently not implemented. So, as long as you can estimate its size and as long as he can prioritize it, it doesn't really matter how you call the way you capture the needs.
So, unless you have to deal with specific contractual constraints, just pick one solution, estimate the size and let the customer prioritize it (personally, I'd create a new user story).
I would edit the old story to document the modification. Otherwise you may have contradictions between the new story and the old one.
This can hardly be considered as a defect (or bug) if the customer changed its mind.
Be pragmatic: estimate it, schedule it and implement it.
I would say this should count as the old story. Your team should report reduced throughput (velocity) because of these changing requirements, especially if the original feature has not already shipped.