2

I was reading this Questions regarding REST

What exactly is RESTful programming?

While reading i get that the client is independent of server and client don't need to construct anything.

I want to know that when we are building forms like user registration . Then what is the REST way of doing it.

I mean when i do GET for /user/new then

  1. Does the server has to send the complete FORM in html
  2. Only send fields in JSON and form is constructed by client itself

But then again there will be many complexities, if i just send the fields, then what things like

  1. Hidden fields
  2. Default value for select boxes
  3. what about some logic like this field can'r be greater than 30 etc
Community
  • 1
  • 1
Mirage
  • 28,544
  • 56
  • 155
  • 251
  • According to [this](http://www.restapitutorial.com/lessons/httpmethods.html), to create new resource (new user in your case), you must use `POST` method, `GET` method oly use to retrieve data. This document will help you understand the purpose of each method like: GET, POST, PUT, DELETE – Doan Cuong Jun 12 '14 at 04:17
  • Basically, for your example of a new user reg form, you would likely serialize the data from your input fields and post that to your rest endpoint. Many client side js frameworks, such as Jquery, provide you shortcuts to do just that. – Tim Jun 12 '14 at 04:18
  • @Tim mine questions is not regarding posting form but displaying form in REST way – Mirage Jun 12 '14 at 04:23
  • well, then that really does not make much sense. REST is a protocol, not a view engine. if you want to bind data from a GET rest call to a view object, such as a grid; you can certainly use rest to fetch data as your data source. Or you can use scaffolding in some frameworks, if the one you are using supports it). – Tim Jun 12 '14 at 04:34
  • 1
    @Tim REST is an ARCHITECTURE, not a protocol.. – LMG Jun 12 '14 at 06:48
  • but you are talking about rest over http... which is what i am talking about. wow. do i really need to explain this further? – Tim Jun 12 '14 at 09:41
  • @Tim I think OP is having issues separating the idea of a browser - which uses HTTP and renders content into a UI - from a REST client which uses HTTP and processes content into code. – Adrian Wragg Jun 12 '14 at 10:13

3 Answers3

1

REST is, as you're already aware, a way of communicating between a client and a server. However, the issue here is what is being defined as the "client". Personally, I tend to consider that the browser itself is not in itself the client: instead, the client is written in JavaScript, and the browser is merely a conduit to executing it.

Say for the sake of argument that you wish to view the details of user '1414'. The browser would be directed to the following location:

/UserDetails.html#1414

This would load the static file ViewUser.html, containing all the form fields that may be necessary, as well as (via a <script> tag) your JavaScript client. The client would load, look at the URL and make a RESTful call to:

GET /services/Users/1414

which would send back JSON data relating to that user. When the user then hits "save", the client would then make the following call:

PUT /services/Users/1414

to store the data.

In your example, you wanted to know how this would work with a new user. The URL that the browser would be directed to would be:

/UserDetails.html#0

(or #new, or just # - just something to tell the JavaScript that this is a new client. This isn't a RESTful URL so the precise details are irrelevant).

The browser would again load the static file ViewUser.html and your JavaScript client, but this time no GET would be made on the Users service - there is no user to download. In addition, when the user is saved, this time the call would be:

POST /services/Users/

with the service ideally returning a 302 to /services/Users/1541 - the location of the object created. Note that as this is handled in the client not the browser, no actual redirection occurs.

Adrian Wragg
  • 7,066
  • 3
  • 26
  • 50
0

There are multiple ways to do what you want.

  • You can use GET for /user/new along with a create-form link relation to get a single link. This can in plain HTML or HTML fragment, or a schema description, practically anything you want (the result will be less reusable than the other solutions).

  • You can use a standard MIME type which supports form descriptions. For example HAL with a form extension or collection+json.

  • You can use an RDF format, like JSON-LD with a proper vocab like Hydra.

inf3rno
  • 20,735
  • 9
  • 97
  • 171
0

"Forms" for hypermedia APIs could be rendered in a "forms aware" media type like for instance Mason (https://github.com/JornWildt/Mason), Hydra (http://www.markus-lanthaler.com/hydra/) or Sirene (https://github.com/kevinswiber/siren). In Mason (which is my project) you could have a "create user" action like this:

{ "@actions": { "create-user": { "type": "json", "href": "... URL to resource accepting the POST ...", "method": "POST", "title": "Create new user", "schemaUrl": "... Optional URL to JSON schema definition for input ..." "template": { "Windows Domain": "acme" } } } }

The client can GET a resource that include the above action, find it be the name "create-user" and in this way be told which method to use, where to apply it, how the payload should be formated (in this case its JSON as described by an external schema definition) and some default values (the "template" object).

If you need more complex descriptions (like selection lists and validation rules as you mention) then you are on your own and will have to encoded that information in your own data - or use HTML or XForms.

Jørn Wildt
  • 3,856
  • 18
  • 31