tmaiaroto/collection+json.md

## collection+json.md

      
    Raw
  

              collection+json.md
            
          
    Collection+JSON format

http://amundsen.com/media-types/collection/examples/
This format takes into consideration collections (much like Siren). It also takes into consideration versioning. However, I'm not certain version matters in the data set if it pertains to an API version. That is best left being in the API URL. It could pertain to collection version, but I'm not sure the point. Documentation says each collection should have a version - but says nothing more about meaning or why.
Items are clearly distinct in this format and are organizationally positioned separate from links.

This is by far the most collision free structure.
However, the data format itself is a bit strange...Every field being an array. Data is always an array of objects. I understand the flexibility this presents and am not 100% against it. I just believe it's perhaps not needed as things could change based on the client application.
QUERIES

The queries section is very nice and something not found in other formats. However, I don't see anything for pagination and I believe it would certainly make sense to include by now.
Collection+JSON puts a lot of emphasis on the display and intended usage of data. Moreso than any other format. This is nice, but unless the client application was attempting to display a layout automatically, I don't see the need. A human engineer can interpret and decide things just fine and perhaps different clients or even access control rules would dictate a different visual representation anyway. Therefore I believe this oversteps the duties a little bit. Still clever and guidance/definition is what we're after of course.
LINKS

I like how links are even more separate from the data here than any other format. Due to this structure, there is no need to prefix with underscores, etc. Links still carry the same "rel" descriptive values which are important for orientation.
However, I would still use "self" instead of "href" for the current item's link for consistency. Again, Collection+JSON puts some emphasis on how these links should appear. For example, the "render" key. However, many of these properties "render" and "prompt" etc. are optional anyway.
The only downside here is that given how much emphasis and careful consideration is put on how data is rendered, there seems to be a lack of emphasis for "actions" or forms.
The "template" section is actually intended to be used as a guide for which data should be sent to the API in these cases (POST and PUT for update, following convention). However, I don't believe it's particularly descriptive. Also, the format states there should only be one form. This isn't a bad rule of thumb, but I could see where an API response may return multiple forms every now and then (related data, etc.).
ERRORS

http://amundsen.com/media-types/collection/examples/#ex-error
Not shown here is another section called "errors" and I feel this is important and worth mentioning. It's very debatable that errors should be contained within HTTP reponse headers...But I believe that, often, additional detail is required and messages being returned in an API are good because it means those messages can be updated from one central location instead of many client application updates. Superior design for maintenance. Additionally, HTTP headers should be kept small and while a status code is obviously present, an entire message intended for a human is perhaps inappropriate.
{ "collection" :
  {
    "version" : "1.0",
    "href" : "http://example.org/friends/",
    
    "links" : [
      {"rel" : "feed", "href" : "http://example.org/friends/rss"}
    ],
    
    "items" : [
      {
        "href" : "http://example.org/friends/jdoe",
        "data" : [
          {"name" : "full-name", "value" : "J. Doe", "prompt" : "Full Name"},
          {"name" : "email", "value" : "jdoe@example.org", "prompt" : "Email"}
        ],
        "links" : [
          {"rel" : "blog", "href" : "http://examples.org/blogs/jdoe", "prompt" : "Blog"},
          {"rel" : "avatar", "href" : "http://examples.org/images/jdoe", "prompt" : "Avatar", "render" : "image"}
        ]
      },
      
      {
        "href" : "http://example.org/friends/msmith",
        "data" : [
          {"name" : "full-name", "value" : "M. Smith", "prompt" : "Full Name"},
          {"name" : "email", "value" : "msmith@example.org", "prompt" : "Email"}
        ],
        "links" : [
          {"rel" : "blog", "href" : "http://examples.org/blogs/msmith", "prompt" : "Blog"},
          {"rel" : "avatar", "href" : "http://examples.org/images/msmith", "prompt" : "Avatar", "render" : "image"}
        ]
      },
      
      {
        "href" : "http://example.org/friends/rwilliams",
        "data" : [
          {"name" : "full-name", "value" : "R. Williams", "prompt" : "Full Name"},
          {"name" : "email", "value" : "rwilliams@example.org", "prompt" : "Email"}
        ],
        "links" : [
          {"rel" : "blog", "href" : "http://examples.org/blogs/rwilliams", "prompt" : "Blog"},
          {"rel" : "avatar", "href" : "http://examples.org/images/rwilliams", "prompt" : "Avatar", "render" : "image"}
        ]
      }      
    ],
    
    "queries" : [
      {"rel" : "search", "href" : "http://example.org/friends/search", "prompt" : "Search",
        "data" : [
          {"name" : "search", "value" : ""}
        ]
      }
    ],
    
    "template" : {
      "data" : [
        {"name" : "full-name", "value" : "", "prompt" : "Full Name"},
        {"name" : "email", "value" : "", "prompt" : "Email"},
        {"name" : "blog", "value" : "", "prompt" : "Blog"},
        {"name" : "avatar", "value" : "", "prompt" : "Avatar"}
        
      ]
    }
  } 
}


## hal.md

      
    Raw
  

              hal.md
            
          
    HAL format

Borrowed from: https://gist.github.com/kevinswiber/3066768

The HAL draft: http://tools.ietf.org/html/draft-kelly-json-hal-06
LINKS

I don't like how "_links" are merged with other data because it's meta data added on top by the RESTful service and relates directly to the API. I feel this makes things slightly confusing and leaves the structure vulnerable to conflicts -- what if the "orders" had their own links field?
In this case it's a bit narrow too. Most people would return the customer details along with the order for example. There would not really be a need to make a second HTTP request to the API to get that data. This is because the client application would likely want to display that information along side. However, there are times when we might want to link out to another page or make another API call. In this specific example, perhaps for the "basket" data.
This dives into relationships and I think Siren is better equipped to handle them. Again, I believe there is an importance in not having to call the API an unnecessary amount of times. Ultimately it should be up to the engineer to decide as well because of special considerations like payload size.
The organization of data is a little confusing as well. This seems to be a listing of orders, and the "_embedded" orders items make sense...But "shippedToday" and "currentlyProcessing" do not make sense where they are positioned. We are to assume, by convention, that this has nothing to do with HAL format (no underscore), but the data fields (whether they came from the data source or were added) are at the same level as _links for example.
What if the data source also had a key name "_links" ? This opens the possibility of conflicts. A data source should never conflict with a conventional organization system and the onus should be on the system and not the data source. There are better organizational structures that can be used which will never conflict.
{
  "_links": {
    "self": { "href": "/orders" },
    "next": { "href": "/orders?page=2" },
    "find": { "href": "/orders{?id}", "templated": true }
  },
  "_embedded": {
    "orders": [{
        "_links": {
          "self": { "href": "/orders/123" },
          "basket": { "href": "/baskets/98712" },
          "customer": { "href": "/customers/7809" }
        },
        "total": 30.00,
        "currency": "USD",
        "status": "shipped",
      },{
        "_links": {
          "self": { "href": "/orders/124" },
          "basket": { "href": "/baskets/97213" },
          "customer": { "href": "/customers/12369" }
        },
        "total": 20.00,
        "currency": "USD",
        "status": "processing"
    }]
  },
  "currentlyProcessing": 14,
  "shippedToday": 20
}


## old-unified-format.md

      
    Raw
  

              old-unified-format.md
            
          
    Unified Hypermedia JSON Format

The following is outdated. See the unified-format.go file for a more up to date draft of ideas.

Here's what my proposed format would look like (rough draft) which combines elements of the above 3 formats and provides a little more (optional) detail along with a little cleaner hierachy. By comparing with the other formats you should easily be able to see similarities and techniques borrowed from each. This format should suit a wider range of applications.
Note that there's a few things not solidified yet and there are many good approaches to those challenges...I just haven't researched which way makes most sense yet. Use your imagination there =)
Also note that this format does not prevent one from having multiple forms/actions in a single response. I believe this is another important characteristic when it comes to designing a flexible structure that works for many applications. I also believe the onus is on the engineer and system architect to ensure things don't get too crazy here with response payload size.
Keep in mind many fields are optional here intentionally to allow for judiciary performance optimizations and flexibility. The Hypermedia JSON format has two broad concerns or goals:
First Goal: Allow engineers to browse API JSON responses and navigate through the API.
Second Goal: Provide a client application guidance on how the server side application operates and how it should be handling data.
The format does not make assumptions about data or actions. While it would be very common to see your normal CRUD operations under _actions, it is not restricted to those operations. It is left open to accommodate the needs of the application.
I don't think there's anything wrong with flexibility to the degree that we would see different, optional, fields across different APIs. There is no one size fits all API. However, the required fields in this format do represent a common set of data that can be used across the vast majority of applications.

I should note that this is very preliminary. I expect to roll some things around in my head and get some feedback to further detail this out.

{
 "_meta": {
  "dataCount": 25,
  "dataLimit": 25,
  "dataTotal": 100,
  "dataOrder": {"created": "desc"},
  "responseTime": 0.004,
  "message": "Everything looking good kemosabe."
 },
 "_http": {
  "code": 200,
  "name": "OK",
  "message": "Optional message with more details...More useful in the event of errors. This section allows for the extension of HTTP status codes (perhaps this is all frowned upon and that's ok, a more generic HTTP status could could be presented in the headers remaining consistent with standards and this _http block could present additional related details for the more adventurous). More importantly, this could handle language translations quite nicely."
 },
 "_links": [
  {"rel": "self", "href": "/posts"},
  {"rel": "next", "href": "/posts/page-2"},
  {"rel": "prev", "href": "/posts/page-1"}
  // NOTE: Route format not solidified, completely open to a good way to present arguments and regex matches, etc.
  {"rel": "skip", "href": "/posts/page-{pageNumber:[0-9]}"},
  // This is why we don't need another "_links" within each item below under "_data" - the client application should be able to logically put it together. This provides for a smaller payload as a nice bonus.
  {"rel": "read", "href": "/posts/read/{id}"}
  // ...additional related links as needed by the application. Also note there can be additional optional keys to help the client application, such as "_target" and HTML attributes, etc. While HTML won't always be the client application language (mobile apps lets say), these are optional and a client application can still assume intent (or disregard).
 ],
 "_data": {
  // A completely flexible data structure - separate from other meta data
  "posts": [
    {"_id": "01234ef", "title": "Boom"}
  ]
 },
 "_actions": {
  "_forms": {
   "formName": {
    // For the most part, HTML attributes dictate the keys here
    "name": "add-post",
    "title": "Add Blog Post",
    "method": "POST",
    "action": "/posts/add",
    "enctype": "application/x-www-form-urlencoded",
    "fields": [
     // Note: Validation convention still not solidified either, there are many good conventions here as well.
     { "name": "title", "type": "text", "validation": [{"rule": "[A-z0-9]\s", "message": "Must be alpha numeric."}] },
     { "name": "authorId", "type": "hidden", "value": "42" }
    ]
   }
  },
  "_errors": {
    "formName": [
     {"name": "title", "message": "Cannot be blank."}
    ]
  }
  
 }
}


## siren.md

      
    Raw
  

              siren.md
            
          
    Siren format

https://github.com/kevinswiber/siren
Siren has the idea of "classes" or collections. This value can be an array of classes which is a little confusing. Top level entities can have sub-entities. In the following example, "properties" represents an entity's data (perhaps from a data source) and entities under it are related.
I like this entities approach better than other proposed structures. Even with the goofy classes...Do arrays represent relationships? If so, why would this not be expressed as key values with key names like "belongsTo"?

Why would the client even care about the relationships?
I haven't seen how Siren handles a top level result set. I imagine only an "entities" key exists with optional "actions" and "links" (where links may not be optional).
I think "entities" is too distinct in this case. I think the "orderNumber" and "status" from the main item should be in the same place as the related data. Yes, the related entities would be sub-items of the parent entity/ies. However, that's up to the application's data design. Let's say we wanted to show a listing of more than one order with all these related details? How would that look? "entities" under "entities" and then where would the top level "properties" go? Would "properties" become an array? If so, how would you ever relate the "entities" to the "properties" ? You couldn't other than perhaps keying things. So representing relationships should be done as children under the parent item and not in a new top level item.
ACTIONS

These are great and other formats will say "_forms" which is also acceptable. The only thing I would add here would be some more (optional) detail. How about field data types? Validation rules? I think validation rules are important because a front-end client can validation locally before sending to the server/API for server side validation.
While server-side validation is always required (to ensure it is not bypassed), relieving an API from unnecessary calls is always a win win for everyone. Faster user experience (less requests over the internet) and less traffic to the server so that it can better do its job and serve more clients.
LINKS

The links in this format contain "rel" values with arrays. I'm not sure the logic behind this. Would it also make sense for a class to go on the links as well? I'm not sure. However, the links are separate from the "properties" which is good. Most other proposed formats use an underscore "_links" to visually separate from other data...But I like things to be separate by hierarchary.
I also believe links shold carry pagination with them, another thing not often seen. Next/prev implies the sense of pagination, but there seems to be no "page" or "skip" link to jump to a specific section.
{
  "class": [ "order" ],
  "properties": { 
      "orderNumber": 42, 
      "itemCount": 3,
      "status": "pending"
  },
  "entities": [
    { 
      "class": [ "items", "collection" ], 
      "rel": [ "http://x.io/rels/order-items" ], 
      "href": "http://api.x.io/orders/42/items"
    },
    {
      "class": [ "info", "customer" ],
      "rel": [ "http://x.io/rels/customer" ], 
      "properties": { 
        "customerId": "pj123",
        "name": "Peter Joseph"
      },
      "links": [
        { "rel": [ "self" ], "href": "http://api.x.io/customers/pj123" }
      ]
    }
  ],
  "actions": [
    {
      "name": "add-item",
      "title": "Add Item",
      "method": "POST",
      "href": "http://api.x.io/orders/42/items",
      "type": "application/x-www-form-urlencoded",
      "fields": [
        { "name": "orderNumber", "type": "hidden", "value": "42" },
        { "name": "productCode", "type": "text" },
        { "name": "quantity", "type": "number" }
      ]
    }
  ],
  "links": [
    { "rel": [ "self" ], "href": "http://api.x.io/orders/42" },
    { "rel": [ "previous" ], "href": "http://api.x.io/orders/41" },
    { "rel": [ "next" ], "href": "http://api.x.io/orders/43" }
  ]
}


## thoughts.md

      
    Raw
  

              thoughts.md
            
          
    Thoughts on Existing Formats

I think they are all well intended, but miss the mark a tiny bit. In fact, I would combine several aspects from each to be honest. To be 100% clear, I generally agree with and appreciate the proposals here, but I think more work is required to really polish things up.
When comparing these formats it's a little bit obvious that there were specific needs in mind. Collection+JSON was obviously targeted more toward NoSQL/schemaless data sources and had a more heavy emphasis on visual representation within the client application than the other formats. Many formats (and there's a few I didn't cover) have a strong emphasis on e-commerce. Obviously e-commerce applications are different than most other systems.
However, what's really important to take away from this is that I think a consolidated format could serve all of these needs and intended use cases. I think each time a new format was created it solved a different problem, but didn't think much about the previous problem being solved. I guarantee a few hours of putting some people's heads together is all we'd need to have a unified format.
Last, I don't think there's enough definition around the "actions" or forms in any of these formats. They all seem to focus on API orientation and navigation more than data managment. This is ok since we have API docs of course (and this format is by no means a replacment for documentation), but I think we can do better.
They all seem to have opened the door or perhaps have their hand on the knob...But they aren't walking through. They should. If you're providing insight on "what" to send back to the API (and under which method), then there should be some context around "how" it needs to look when it gets there. Especially if you want to dictate validation from a single point that can be easily updated without the need for client application updates. My reasoning here is because doing so is a win win win scenario:
Win #1: The API is hit less frequently which allows it to serve more clients without the need to scale so you're winning on costs too in the long run (win 1.5), but this means more stability for your API.
Win #2: Again, less maintenance. Faster development cycles. You do not need to update the client applications if they obey the rules coming from the JSON response. How many client applications might you have? This could be a major improvement on the maintenence considerations of your application and API.
Win #3: It's faster for the end user! I know we live in a broadband world, but if you think about it in terms of mobile apps or even complex JavaScript browser apps, your application will be more reponsive if it doesn't need to make that round trip request to validate data (as often). Obviously this is not intended to be a guarantee so you should always keep server-side data validation in place, but the more you can do up-front, the more responsive things will be. Better user experience. More importantly you now know any front-end (JavaScript or otherwise) validation is in sync with your back-end validation because you aren't redefining rules in JavaScript or something on the front-end. You're just reading them. Go look at some jQuery form validation plugins and what people have done in the past, all the duplicate work, and you'll quickly appreciate this direction from the API.
My Combinations

So what would I combine? Well, I like the underscore notation. I think while there may be fields in one's data source with underscores (think MongoDB's _id for example off the top of my head - and I personally use them in MongoDB to denote relationships), it is still good to use for visual distinction for an engineer. Especially when these fields are top level items in the JSON response. An engineer can very quickly see that it's part of the Hypermedia convention and isn't something coming from the data source (or perhaps it is - but they'll easily know when).
Separation of Data

This brings me to hierarchy. It's super important. Mixing data from the data source with additional meta data is a bad idea. Especially the common term "links" ... Of course there could be a "links" key from the data source with all sorts of values and meaning. If one of the goals of Hypermedia JSON is to present the engineer with an easy to understand (and navigatable) response, then I think any confusion would put the format at risk of failing to meet that goal. In some cases, it may even become impossible to use the format with the data set unless aliases were used for field names.
While a complete data dump may be an unfavorable design practice, I still don't believe the API response and the data source should be that far apart. While the end-user engineer may not care (or know any better), the internal engineers who are developing the system should also not need to be bothered with any unnecssary field mapping or aliasing. What got moved where for this particular API and nothing else? What do they call this field in this particular response? etc. It introduces a maintenance problem. Anytime there's confusion and additional maintenance time, business goals and costs suffer. No matter how awesome an engineer may believe something to be, there are real world factors and goals and budgets that must be cosidered.
So keep meta data and application data organizationally separate and distinct. It's extremely important. This is why most formats separate out "links" in the first place. However, if you see them embedded within each item, I still think it's a problem (unless each item is an object with a "data" key and a "links" key as with Collection+JSON). I would prefer instead, routing rules like what HAL suggests.
So I would provide a ``_data``` wrapper for the items coming back from the data source. Essentially like "items" in Collection+JSON. I would not go so far as to show relationships in the data like Siren or HAL. I think this assumes too much and not every application will have the same needs or schema. I don't think we can ever replace the need for API documentation or a general understanding of the application's data. Likewise, APIs don't point guns to people's heads saying you must use every bit of data I give you! =)
Actions & Forms

I think Siren put the most thought into forms or actions. There is no confusion about the HTTP method that the API will accept and the response and this is nice because it means your API is truly more navigatable than most others. Think about the time you'll be saving not referencing up the API docs for example. This leads to faster and easier development. Plus, your client application can be a bit more dynamic and take instruction so that you may end up with less maintenance.
So I would take the way Siren handles actions and replace Collection+JSON's "template" section which is a little confusing anyway. When we see "template" we don't really think about forms and actions. Plus, there's more detail within the action items.
However, I would add to this even more (of course optional) information for validation rules. I think Siren hits the nail on the head here in terms of providing form element types and default values...But I would also add optional placeholder keys. Though the validation rules I think are super important. These can even come with messages. If all this comes from the API then maintenance is easy on the server side and again there's that win win win situation here for user experience and API health.
I would also add an _errors key to the forms/actions section. All forms would be given a name and this object would then have named forms with their errors so that a client application knew exactly how to display and handle the errors. Collection+JSON introduces errors, but they seem to be unrelated to the "template" section.
HTTP Errors

Yes, this is what HTTP headers are for. However, I believe additional information may be desired by certain APIs. Anything outside of HTTP response header standards, etc. I also don't believe the headers are an appropriate place for lengthy messages. I think HTTP status codes are great, but they are short codes in the first place for a reason. I would include an _http key with an object value that contained additional error details, similar to Collection+JSON and perhaps even more depending on the needs of the application. This provides better flexibility.
Messages

One thing you don't see a lot of here are messages. "Flash" messages are quite common in applications to help notify the user that something saved properly or there was an error, etc. Of course with form validation we also have the need for messages. They should all be strings and any internationalization considerations should be taken care of in the API URL. /en/posts or /es/posts for example. While one might consider putting translations in the response itself, I think this would unecessarily increase the payload size and most client applications would have no need to display more than one language at a time.
Meta

I would add a _meta key with values for extra things like pagination, response time, flash message, etc. If you're dealing with a listing of items, this is a great place for a total count, sorting options, pagination, etc. It's also nice to get a response time from an API. This should always be held separate from the other data.
Links

Again, I would keep _links separate from the data. This is data added on top of the application data that has more to do with the API than it does the actual application. So there's absolutely no reason to mix it in with the data. Also, I think it's ok to use routing logic here like HAL does. However, HAL mixes in "_links" as if it was data coming straight from the data source along with everything else. I believe to avoid conflicts and to stay better organized, it should just be moved a little bit. Simple change and Collection+JSON does this.
Versioning

I think we should follow semantic versioning in our APIs. Maybe the level of detail is a bit silly at times, but loosely we should follow it. I don't believe in the "v1" we commonly see and I think I'm not alone in this. If you look at Twitter's API, you'll notice they don't use "v" in their version number.
The API version number is contained in the API URL and it is the first item. I agree with this positioning and format. While we never see a real need for "patch" I think "major" and "minor" are more common enough. I think the version number should be kept out of the response as well. Though it wouldn't hurt to optionally add it to the meta data, it does belong in the URL.
Locale/Internationalization

Locale also belongs in the URL. One should not POST arguments for the language. It should be set (preferable immediately following API version number) in the URL. This could even be optional with a default to a specific language. If the API does not support internationalization, then of course we wouldn't expect to see it.

  
## unified-format.go
// Inspired by a few hypermedia formats, this should allow for HAL compatible JSON. However, it deals with more than resources and links.
// It puts more structure around two way communication whereas HAL just tells you what resources are available and where to find them....
// This unified format takes the concerns from formats like Siren and adds them on top of HAL. Yes, with some slight modifications all around.

// This HAL inspired resource includes "_links" and "_embedded" but also adds "_data", "_meta", and "_forms" for enhancements and keeping things tidy.
// Additionally, there's "_curies" which pulls HAL's "curies" out from "_links" and up to its parent. Why? Mainly because "curies" isn't a valid IANA link relation.
// Another reason for breaking it out of "_links" is that CURIEs can be used elsewhere. For example: <html xmlns:news="..."> etc. See: http://www.w3.org/TR/curie
// So now each resource defines the CURIEs it will use. This removes a limitation by HAL.
type HypermediaResource struct {
	Meta     HypermediaMeta                `json:"_meta"`
	Links    map[string]HypermediaLink     `json:"_links,omitempty"`
	Curies   map[string]HypermediaCurie    `json:"_curies,omitempty"`
	Data     map[string]interface{}        `json:"_data,omitempty"`
	Embedded map[string]HypermediaResource `json:"_embedded,omitempty"`
	Forms    map[string]HypermediaForm     `json:"_forms,omitempty"`
}

// The Meta structure helps with common (but optional) info useful for working with data (pagination) and handling errors.
type HypermediaMeta struct {
	Success      bool              `json:"success"`
	Message      string            `json:"message"`
	ResponseTime float32           `json:"responseTime"`
}

// HAL compatible link structure plain and simple (somewhat compatible with http://tools.ietf.org/html/rfc5988).
// NOTE: in HAL format, links can be an array with aliases - our format has no such support, but this doens't break HAL compatibility.
// Why not support it? Because that changes from {} to [] and I don't want to change data types. If it's common enough then maybe always array/slice.
// Also, each "_links" key name using this struct should be one of: http://www.iana.org/assignments/link-relations/link-relations.xhtml unless using CURIEs.
type HypermediaLink struct {
	Href        string `json:"href"`
	Type        string `json:"type,omitempty"`
	Deprecation string `json:"deprecation,omitempty"`
	Name        string `json:"name,omitempty"`
	Profile     string `json:"profile,omitempty"`
	Title       string `json:"title,omitempty"`
	Hreflang    string `json:"hreflang,omitempty"`
}

// Defines a CURIE
type HypermediaCurie struct {
	Name      string `json:"name,omitempty"`
	Href      string `json:"href,omitempty"`
	Templated bool   `json:"templated,omitempty"`
}

// Form structure defines attributes that match HTML (whereas "links" and "resources" do not).
// Any attribute not found in HTML should be prefixed with an underscore (for example, "_fields").
// NOTE: Not in the HAL spec, this extends the hypermedia format to allow for additional CRUD support.
type HypermediaForm struct {
	Name          string                         `json:"name,omitempty"`
	Method        string                         `json:"method,omitempty"`
	Enctype       string                         `json:"enctype"`
	AcceptCharset string                         `json:"accept-charset,omitempty"`
	Target        string                         `json:"target,omitempty"`
	Action        string                         `json:"action,omitempty"`
	Autocomplete  bool                           `json:"autocomplete,omitempty"`
	Fields        map[string]HypermediaFormField `json:"_fields,omitempty"`
}

// Defines properties for a field (HTML attributes) as well as holds the "_errors" and validation "_rules" for that field.
// "_rules" have key names that map to HypermediaFormField.Name, like { "fieldName": HypermediaFormFieldRule } and the rules themself are named.
// "_errors" have key names that also map to HypermediaFormField.Name
type HypermediaFormField struct {
	Name         string                              `json:"name,omitempty"`
	Value        string                              `json:"value,omitempty"`
	Type         string                              `json:"type,omitempty"`
	Src          string                              `json:"src,omitempty"`
	Checked      bool                                `json:"checked,omitempty"`
	Disabled     bool                                `json:"disabled,omitempty"`
	ReadOnly     bool                                `json:"readonly,omitempty"`
	Required     bool                                `json:"required,omitempty"`
	Autocomplete bool                                `json:"autocomplete,omitempty"`
	Tabindex     int                                 `json:"tabindex,omitempty"`
	Multiple     bool                                `json:"multiple,omitempty"`
	Accept       string                              `json:"accept,omitempty"`
	Errors       map[string]HypermediaFormFieldError `json:"_errors,omitempty"`
	Rules        map[string]HypermediaFormFieldRule  `json:"_rules,omitempty"`
}

// Error messages from validation failures (optional) "name" is the HypermediaFormFieldRule.Name in this case and "message" is returned on failure.
type HypermediaFormFieldError struct {
	Name    string `json:"name"`
	Failed  bool   `json:"name"`
	Message string `json:"message,omitempty"`
}

// Validation rules! Easily nested into "_rules" on "_fields" (optional).
type HypermediaFormFieldRule struct {
	Name        string `json:"name"`
	Description string `json:"description,omitempty"`
	// Careful, regular expressions need to be escaped properly, but it can provide for front-end validation before data is submitted (of course not to be trusted)
	Pattern string `json:"pattern"`
	// This isn't for JSON, it's for Go (because we dont't trust front-end validation)
	Function func(value string) (fail bool, message string)
}
	// Inspired by a few hypermedia formats, this should allow for HAL compatible JSON. However, it deals with more than resources and links.
	// It puts more structure around two way communication whereas HAL just tells you what resources are available and where to find them....
	// This unified format takes the concerns from formats like Siren and adds them on top of HAL. Yes, with some slight modifications all around.

	// This HAL inspired resource includes "_links" and "_embedded" but also adds "_data", "_meta", and "_forms" for enhancements and keeping things tidy.
	// Additionally, there's "_curies" which pulls HAL's "curies" out from "_links" and up to its parent. Why? Mainly because "curies" isn't a valid IANA link relation.
	// Another reason for breaking it out of "_links" is that CURIEs can be used elsewhere. For example: <html xmlns:news="..."> etc. See: http://www.w3.org/TR/curie
	// So now each resource defines the CURIEs it will use. This removes a limitation by HAL.
	type HypermediaResource struct {
	Meta HypermediaMeta `json:"_meta"`
	Links map[string]HypermediaLink `json:"_links,omitempty"`
	Curies map[string]HypermediaCurie `json:"_curies,omitempty"`
	Data map[string]interface{} `json:"_data,omitempty"`
	Embedded map[string]HypermediaResource `json:"_embedded,omitempty"`
	Forms map[string]HypermediaForm `json:"_forms,omitempty"`
	}

	// The Meta structure helps with common (but optional) info useful for working with data (pagination) and handling errors.
	type HypermediaMeta struct {
	Success bool `json:"success"`
	Message string `json:"message"`
	ResponseTime float32 `json:"responseTime"`
	}

	// HAL compatible link structure plain and simple (somewhat compatible with http://tools.ietf.org/html/rfc5988).
	// NOTE: in HAL format, links can be an array with aliases - our format has no such support, but this doens't break HAL compatibility.
	// Why not support it? Because that changes from {} to [] and I don't want to change data types. If it's common enough then maybe always array/slice.
	// Also, each "_links" key name using this struct should be one of: http://www.iana.org/assignments/link-relations/link-relations.xhtml unless using CURIEs.
	type HypermediaLink struct {
	Href string `json:"href"`
	Type string `json:"type,omitempty"`
	Deprecation string `json:"deprecation,omitempty"`
	Name string `json:"name,omitempty"`
	Profile string `json:"profile,omitempty"`
	Title string `json:"title,omitempty"`
	Hreflang string `json:"hreflang,omitempty"`
	}

	// Defines a CURIE
	type HypermediaCurie struct {
	Name string `json:"name,omitempty"`
	Href string `json:"href,omitempty"`
	Templated bool `json:"templated,omitempty"`
	}

	// Form structure defines attributes that match HTML (whereas "links" and "resources" do not).
	// Any attribute not found in HTML should be prefixed with an underscore (for example, "_fields").
	// NOTE: Not in the HAL spec, this extends the hypermedia format to allow for additional CRUD support.
	type HypermediaForm struct {
	Name string `json:"name,omitempty"`
	Method string `json:"method,omitempty"`
	Enctype string `json:"enctype"`
	AcceptCharset string `json:"accept-charset,omitempty"`
	Target string `json:"target,omitempty"`
	Action string `json:"action,omitempty"`
	Autocomplete bool `json:"autocomplete,omitempty"`
	Fields map[string]HypermediaFormField `json:"_fields,omitempty"`
	}

	// Defines properties for a field (HTML attributes) as well as holds the "_errors" and validation "_rules" for that field.
	// "_rules" have key names that map to HypermediaFormField.Name, like { "fieldName": HypermediaFormFieldRule } and the rules themself are named.
	// "_errors" have key names that also map to HypermediaFormField.Name
	type HypermediaFormField struct {
	Name string `json:"name,omitempty"`
	Value string `json:"value,omitempty"`
	Type string `json:"type,omitempty"`
	Src string `json:"src,omitempty"`
	Checked bool `json:"checked,omitempty"`
	Disabled bool `json:"disabled,omitempty"`
	ReadOnly bool `json:"readonly,omitempty"`
	Required bool `json:"required,omitempty"`
	Autocomplete bool `json:"autocomplete,omitempty"`
	Tabindex int `json:"tabindex,omitempty"`
	Multiple bool `json:"multiple,omitempty"`
	Accept string `json:"accept,omitempty"`
	Errors map[string]HypermediaFormFieldError `json:"_errors,omitempty"`
	Rules map[string]HypermediaFormFieldRule `json:"_rules,omitempty"`
	}

	// Error messages from validation failures (optional) "name" is the HypermediaFormFieldRule.Name in this case and "message" is returned on failure.
	type HypermediaFormFieldError struct {
	Name string `json:"name"`
	Failed bool `json:"name"`
	Message string `json:"message,omitempty"`
	}

	// Validation rules! Easily nested into "_rules" on "_fields" (optional).
	type HypermediaFormFieldRule struct {
	Name string `json:"name"`
	Description string `json:"description,omitempty"`
	// Careful, regular expressions need to be escaped properly, but it can provide for front-end validation before data is submitted (of course not to be trusted)
	Pattern string `json:"pattern"`
	// This isn't for JSON, it's for Go (because we dont't trust front-end validation)
	Function func(value string) (fail bool, message string)
	}