I am starting from the Maven chat example and would like to extend it so that multiple independent chats can happen at different URL paths. For now I would be satisfied mapping multiple pages to the index.
My best guess is to put something like Lift RewriteResponse not finding a valid url in the boot strap class. But so far nothing I have tried works.
I am a bit frustrated by the lack of well explained examples on how to do path mapping for different common use cases (same goes for most lift documentation).
Please see http://simply.liftweb.net/index-3.2.html#toc-Subsection-3.2.7
This section describes how to use parameterized URLs.
If you want an example of multiple chat rooms, please download http://tunaforcats.com/ chat_done.tgz
Thanks!
Related
I am currently working on a Hapi-FHIR project.
There I want to implement a collection of Questionnar Responses by Patient. The collection gives back all QuestionnaireResponses of a Patient with a given PatientId.
This works without problems but I also want to adhere to the REST Resource Naming Conventions.
So the search URL for my Collection shoud look something like
https://example.com/patient/{id}/questionnaireresponses.
Right now my search URL looks like this:
https://example.com/QuestionnaireResponse?patient={id}
I already tried to set my own search Url with #Path("/patient/{id}/questionnaireresponses") but HAPI-FHIR seems to ignore this.
I searched the HAPI-FHIR documentation already but I did not find anything related.
My question is where does the naming of the search urls happen in HAPI-FHIR and how can I change the name of a search url?
While I also find the FHIR naming and syntax choices a bit annoying, they're an integral part of the FHIR specification, not specific to Hapi. If you change them, your server won't be usable by a client that is expecting the standardized FHIR API. Which kind of defeats the point of using FHIR, no?
It might well be trivial to change the resource name in a Hapi server request (Patient to patient or patients), but since it doesn't really make that much sense, it might not be. So technically you might be forced to prehandle requests to support even that part of your syntax.
For the kind of hierarchical interrogation that you want, (patient/{id}/questionnaireresponses), things are more complicated even pure semantically, because there might be more than one relationship between two resource types. Even for your example, would patient/{id}/questionnaireresponses return just the responses where the patient is the subject, or also those where he is only the author? And how would you retrieve just those he has authored? FHIR is designed to be as explicit as possible to avoid different interpretations that can lead to wrong information being sent.
HapiFhir offers a mechanism for grouping two resources together.
Using compartments solved my problem.
I am able to achieve friendly urls in Liferay 6.2 CE as follows: localhost:8080/pagename/mapping/dynamic-id
But I want it as below:
localhost:8080/pagename/dynamic-id
OR
localhost:8080/mapping/dynamic-id
Is there a way to do this?
There is no official, neither simple way which you can already achieve what you want. Neither I wouldn't recommend it at all for common requests. Portal architecture defines it this way because, each request should clearly define informations such as:
page destination (which one?)
portlet (which one?)
portlet instance id (when instanceable=true)
some specified portlet context information
As you can see, removing any of these information can lead to situation where request can be understood in more than one way (which page? which portlet on page? which instance? which action?)
If there is no some serious reason, I wouldn't try to fight with this, since this can lead to some other problems in future. If there is no other way, just provide more information, so we maybe can find some workaround solution for your case.
I'm building an application using Durandal 2. I want to define multiple routes using the same VM/View for different context.
Exemple :
/sectionA/:id/home using module ID /viewmodels/home
/sectionB/:id/home using module ID /viewmodels/home too
At first, sectionA and sectionB are meant to use the exact same VM and Views. But, eventually, they will be different. This is not where the issue is since when they'll be different, they'll have their very own VM and shared views (using MVC partials) which will work straight out the box.
The point is, for as long as the page are the same, we don't want to duplicate the VM and Views, generating a lot of garbage for nothing.
I tried the example shown above but that doesn't seems to be possible to do this. Whether the routes are different, it seems that the router cannot make the difference between the two routes and just throw a "route not found" exception although the route is defined in our route definition file.
So the question, is it possible to define two route, with obviously different routes definitions, but using the same moduleId?
If more details are require, don't hesitate to ask for clarifications.
Thanks! :)
I just began looking at REST and was wondering what the basic difference between the two representations was. The first one looks pretty nice to me and the second one has to pass some attribute values but the underlying logic seems to be boiling to almost the same thing (I could be mistaken though)
http://url/category/category_id/item_id
AND
http://url/category?category_id={12}&item_id={12334}
I think you are labouring under some fundamental misconceptions about what REST is about.
The URL used to access a resource really is a detail and actually should not matter to the client. URL's should really be "discovered" by clients anyway if they follow the HATEAOS principe that is one of the tenets of REST.
Essentially you are right though: either URL could represent the resource you are exposing in the end, but as I say, this really is a detail and it comes down to preference in many cases at what URL you expose something. The point of HATEOAS is to allow you to change the URL's that are used to access resources at-will without affecting clients that work against your existing services.
The following URL's might help you understand some of the properties that make services truly RESTful:
How to GET a cup of coffee
Describing RESTful Applications
[disclaimer: just because HATEAOS is a principle of REST does not make it easy to do. You will find most of the services on the web do not follow this principle strictly at all, as evidenced by their documentation which is full of URL templates; not the way services should be documented in the ideal world. I'm struggling myself to find good examples of truly RESTful services and clients...]
It should be possible for agents to reason about the resource structure:
based on the URL, and
based on links returned by requests for resources.
The problem with the second representation is that it can be considered as a set unordered keys and values, with no real structure/heirarchy.
If you click the button from your tag restful-url you get a good link from this site explaining the difference between those two styles:
How to obtain REST resource with different finder "methods"?
What is the benefit of referencing resources using globally-unique URIs (as REST does) versus using a proprietary id format?
For example:
http://host.com/student/5
http://host.com/student?id=5
In the first approach the entire URL is the ID. In the second approach only the 5 is the ID. What is the practical benefit of the first approach over the second?
Why does REST (seem to) go out of its way to advocate the first approach?
-- EDIT:
My question was confusing because it really asked two separate questions:
What is the benefit of addressibility?
What is the difference between the two URI forms seen above.
I've answered both questions below using my own post.
The main thing when i see uri's like that is a normal user would be able to remember that uri.
Us geeks are fine with question marks and get variables, but if someone remembers http://www.host.com/users/john instead of http://www.host.com/?view=users&name=john, then that is a huge benefit.
I will answer my own question:
1) Why are URIs important?
I'll quote from RESTful Web Services by Leonard Richardson and Sam Ruby (ISBN: 978-0-596-52926-0):
Consider a real URI that names a resource in the genre “directory of resources about
jellyfish”: http://www.google.com/search?q=jellyfish. That jellyfish search is just as
much a real URI as http://www.google.com. If HTTP wasn’t addressable, or if the Google
search engine wasn’t an addressable web application, I wouldn’t be able to publish that
URI in a book. I’d have to tell you: “Open a web connection to google.com, type ‘jellyfish’
in the search box, and click the ‘Google Search’ button.
This isn’t an academic worry. Until the mid-1990s, when ftp:// URIs
became popular for describing files on FTP sites, people had to write
things like: “Start an anonymous FTP session on ftp.example.com. Then
change to directory pub/files/ and download file file.txt.” URIs made
FTP as addressable as HTTP. Now people just write: “Download ftp://
ftp.example.com/pub/files/file.txt.” The steps are the same, but now they
can be carried out by machine.
[...]
Addressability is one of the best things about web applications. It makes it easy for
clients to use web sites in ways the original designers never imagined.
2) What is the benefit of addressibility?
It is far easier to follow server-provided URIs than construct them yourself. This is especially true as resource relationships become too complex to be expressed in simple rules. It's easier to code the logic once in the server than re-implement it in numerous clients.
The relationship between resources may change even though the individual resource URIs remain unchanged. For example, if Google Maps were to change the scale of their map tiles, clients that calculate relative tile positions would break.
3) What is the benefit of URIs over custom IDs?
Custom IDs identify a resource uniquely. URIs go a step further by telling you where to find it. This simplifies the client logic.
Search engine optimization mostly.
It also makes them easier to remember, and cleaner, more professional looking in my opinion.
The first is more aesthetically pleasing.
Technically there is no difference, but use the former when you can.
As Ólafur mentioned, The clarity of the former url is one benefit.
Another is implementation flexibility.
Let's say that student 5 changes infrequently. If you use the REST-style url you have the option of serving a static file instead of running code. In Rails it is common that the first request to students/5 would create a cached html file under your web root. That file is used to serve subsequent requests w/o touching the backend. Naturally, there's nothing rails specific about that approach.
The later url wouldn't allow for this. You can't have url variables (?, =) in the names of static pages.
Both URIs are valid from a REST perspective, however just realize that web caches treat the querystring parameters very differently.
If you want to use caching to your advantage then I suggest that you do not use a query string parameter to identify your resource.
I think it comes down to how closely you want to adhere to the principles of feng shui.