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.
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
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.
I want to set up a login page in which from anywhere on the site I can send a user to it and it will display a custom message along with it. I could use a redirect and a msg query param but is this the best way to do it?
I'm working with node.js but I'm interested in a universal solution.
If you are going for easy, you can just have GET data in the URL. But, that doesn't look that nice, if you want a rather long message, plus, GET has size restrictions, where POST (virtually) hasn't.
For using post data you could use the solution of this: JavaScript post request like a form submit question, but that gives a rather messy source code (if you want a somewhat longer text).
You could keep them in a database, and only send the ID of the message to a PHP page, and get it from the database (that's what I would do, but that doesn't mean it's a good idea, just amateur here!)
You can use jQuery or simply plain javascript to extract your message from the url; the relevant question that listed links to detailed code: jquery get querystring from URL.
Then depending on how you want it displayed, apply the extracted string to your situation.
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'm a relative MVC noob coming from WebForms. I think I have a pretty good grasp of MVC with a couple exceptions, and I think I may have broken the pattern. I'm gonna try to keep this short, so I'm assuming that most of what I am asking is relatively obvious.
Let's say I have a news site with articles. In that case, a URL in the form of mynewssite.com/Articles/123 works just great because I don't care who views which article. The user can change the ArticleID in the URL to whatever they want and pull up that article. In my case, however, I only want the user to be able to view/edit data entities (articles, or whatever) that belong to them. To achieve this, I am using their UserID (GUID) as a foreign key in the database, and displaying a list of their data for them to choose from. Here comes the problem... when they click on the link that is created by Url.Action("Edit", New With {.id = item.id}) (I'm not using ActionLink because I need to add HTML content inside the link), the id shows up as a querystring parameter. I could add a route for it, but the id would still show up in the URL for them to tamper with. The obvious implication is that by tampering with the URL, they could view/edit any entity that they want.
What am I missing?
Is there a good way to pass the parameters without adding them on the URL? I know that I could put them in a form on the page and submit the form, but that seems cumbersome for my example, and I'm using jQuery.ajax in places that seems to conflict with this idea.
I could also check their UserID against the data in the Edit method, but that also seems cumbersome, too.
Is this question too broad? Please let me know what specifics you need. Thanks.
Even in Winforms, you would have to add special logic on each request to filter only the articles that the user owns. I don't see why MVC should be any different. Sure, you can use web.config to deny access to given url's, but not when you use a single page that takes a parameter of what data to show.
Your best bet is probably to filter this at the database level. By adding a where clause that includes the user id, then the app will return a "no records found" sort of error, and you can do whatever you want with it.
You could use forms authentication. This way when the user authenticates an encrypted cookie will be emitted which will contain his username which cannot be tampered with. Then you could verify whether the currently connected user has authorizations to edit this article.