In a Play app I'm designing, these are some of my routes
POST /visits controllers.Visit.create
GET /visits controllers.Visit.visits
GET /visits/:id controllers.Visit.visit(id: Long)
PUT /visits/:id controllers.Visit.update(id: Long)
DELETE /visits/:id controllers.Visit.delete(id: Long)
I'm supporting a browser interface too. I'm following with the guidance I saw here:
RESTful on Play! framework
I can easily provide an HTML template to display detailed information about one specific visit, or a list of visits. But how does an "edit page" fall cleanly into this, which would have to be prefilled with the information from a particular visit? I can easily do something like: GET /visits/:id/edit controllers.Visit.edit(id: Long) which would return a prefilled page with the visit information, or I can have a static HTML page which calls the /visits/:id with an AJAX call to populate the fields, and this would let me avoid corrupting my resource-driven API with a browser page-specific route. Or is there some better option? What is best practice and why?
In REST it doesn't make sense for you to create additional resources simply to perform standardized actions. Everyone who knows the HTTP protocol knows your visit object should be editable through a PATCH request with the diff you want to be applied, or through a PUT request that replaces the whole resource with a new one. Why create a custom and non-standard edit action with POST, that you will have to document and explain to everyone how it works?
In that sense, I'd say your best option is having a static HTML page that drives your API, using a GET on /visits/:id to populate the fields, and use the edited content to replace /visits/:id with a PUT when submitted.
However, keep in mind that there's nothing wrong with having a browser page-specific route in your API, as long as you're respecting the Accept header sent by the client. On my APIs, I sometimes have some routes returning a human friendly representation of the resource when the request is made using the Accept: text/html header, so it's a simple way to have a builtin admin client and the API can be easily explored with a browser. In REST, the only difference between an API and a WEB page is that the first returns a representation in a machine-friendly format, and the second a representation that you expect to be rendered by a browser in a human-friendly document. Both of them are supposed to have the links and/or forms with directions on how to edit the resource.
Related
I have a question about HTTP method mapping based on RESTful architecture. This is a really widely discussed topic, I know, but I can't find a useful example, unfortunately.
What I'm interested in is how I should map "create new" page to an HTTP request/URL. Most web-application use AJAX with popups or something similar, so there's no difference between a list of resources(users/) and a creation of a new user(users/), and hence the creation is not bookmarkable, which is justifiable, for sure, since in general why would one want to bookmark a page with a bunch of input fields if they will be empty anyways and all the data should be filled from scratch.
Incidentally, SO uses "questions/ask". What do you use/prefer and what is more RESTful-compliant in your opinion?
I mostly use GET /users/new to serve creation form and POST /users/new to submit the form
My web site has a design where a grid of records is shown. For each record the user might edit it (a GET request) or change its status (this should be a PUT). Do I have a way of doing this without using Javascript?
That is, my current options are:
Use Javascript in a link handler to change the request type as needed.
Separate the GET and PUT activities to separate web pages.
Do the status change via a GET and turn a blind eye to REST specifications right here.
Are there other options?
Thanks,
Jerome.
A GET should not have any side-effects and a PUT would replace the whole resource at the location given by the URI. So the former should be a POST. The latter should be as well, unless it does in fact send the whole resource. A POST is possible without Javascript, obviously.
These days modern sites are becoming more and more service oriented like facebook/gmail.
A main page is loaded and then with ajax requests it calls all sorts of data and adds them on the site. This is also something that is promoted on ASP.NET MVC4 with the Web API.
So now lets say we want to create a product category page for a eshop. It has come to my understanding that the way to go with this implementation is to create a nice layout and create a Web API that will retrieve all data on request.
So we'll have a url like
/api/Products
that will retun a json with all of our products and then we can build up with this api by adding filters/paging maybe (/api/Products?sort-by=name) or anything else that will return the filtered json and we can pass with ajax requests back and forth offering the user an excellent experience.
My question with this now is what happens with SEO.
So a few years ago without onepage ajax/service oriented sites we would have
http://website.com/apples/
http://website.com/apples/2/
that would load the list of the apples with pagination.
Now the site would be
http://website.com/apples/
however it wouldn't load the apples instantly but load a blank page and call the service
/api/apples
that would return a json and then load the data on the site.
I read this article at Google https://developers.google.com/webmasters/ajax-crawling/docs/html-snapshot which didn't convince me. I really don't want to load the service behind and then string replace.
It is possible to have the
http://website.com/apples/
that would call the service
/api/apples
and load the data and be at the same time Google friendly?
You have a couple of options. Either you can use HTML5 pushState to update the URL, but then you also will need to create a version of your site that works without JavaScript turned on.
Another option is to use Googles AJAX Crawling specification. I don't know which search providers that currently supports it, but should be a good way to at least get into Googles search results.
When I GET from http://example.com/organization/ I get a list of organizations.
When I GET from http://example.com/organization/xyz/ I get the record for the organization xyz.
When I POST form data to http://example.com/organization/ I create a new organization.
What URL should I use to GET a form to fill out to create a new organization via a POST to http://example.com/organization/?
Looking at How to do a RESTful request for an edit form? and other sources, it would seem that I am really looking for a form resource for organizations -- so I should GET that form at something like http://example.com/organization/form/ and POST to http://example.com/organization/ as described above. This seems...untidy though.
Update
tuespetre's comments have me thinking the best way to do this is to have a form resource. The organziation form is provided via a GET to /form/organization/ which is filled out and posted to /organization/.
A form in the sense that you speak of one is not a resource, but a template to gather user input to POST a new resource.
One really 'RESTful way' to do it would be to utilize some Javascript to 'include' that form in the collection page /organizations, either as a hidden 'slide-down' form or maybe a modal dialog that appears when a certain call to action button is pressed. This would make semantic sense for two reasons:
You won't have to have some arbitrary URI being used for the form (which is not really a resource in the sense that your domain objects are), and
the 'create' form is for POSTing to the collection, so it really closely relates to that collection and thus would not be at all out of place to have right there with the collection.
Of course, you will find many opinions on this, but I would rather not have arbitrary URIs that break the established pattern (i.e., you're not getting an organization with an id of 'new', so why have that inconsistency?)
If you're trying to implement it, I've seen it done in different ways and I don't think there's a rule (but there are different patterns/approachs that you could follow or not).
I would make it http://example.com/organization/new/
I have a jsp form which takes in user details. On submit button it goes to a jsp page where the details are entered into the database. But before that I would like to check if the username is available as soon as the user clicks the check availability button. How can this be done?
2 ways:
Just redisplay the same page after submitting the form wherein you conditionally display the validation message. This is rather trivial and already covered in the Hello World example in our Servlets wiki page.
Use Ajax to send an asynchronous HTTP request and manipulate the HTML DOM based on the response of the request. This requires a bit more in depth understanding of how websites really work and what JavaScript is. You can find some concrete examples in How to use Servlets and Ajax?
Use AJAX(Asynchronous Javascript and Xml). Its the best web2.0 technology. You can manipulate DOM based on the answer from server