Custom jQuery Request Object - should I move my implementation to my markup?

I am developing a front end request/data management system in order to clean up/organize my API calls/refactor how I interface with my backend platform. I am extending the jquery ajax api call to interface with it and I am looking for some advice on where to stick api-specific implementation.

开发者_Go百科please keep in mind this is a web-application platform and I am trying to make it easier to manage front-end components

The goal is to take defining a request from something like...

var requestObj = new Object();
requestObj.callback = function(responseObj){deleteUserComplete(responseObj); };
requestObj[0] = new Object();
requestObj[0].module = "usermanager";
requestObj[0].context = "#someTable";
requestObj[0].action = "DELETE_USER";
requestObj[0].dataObj = new Object();
requestObj[0].dataObj.userId = $("#ui-tabs-4 .az-switch-panel-off input[name$=userId]").val();

To...

$("button.apiSubmit").apiManager('submitApi');

or

var options = {};
options.callback = someFunction;
options.context = "#someTable";
//etc...
$("button.apiSubmit").apiManager('submitApi', options);

I'm sure you get the idea... but i want to move the ugly request object creation to a factory-type object (mainly just processing forms into objects my backend understands) and moving the api-specific implementation (module, action, context etc) to the markup.

Now for the question(s)...

1) What are the benefits/pitfalls of moving my api-specific request information to the markup?

2) (again, pretty much convinced moving request info to the markup is the right move) class tags or html5 data attributes (x-browser isn't an issue... they are internal apps)?

EX: of class attributes would be... class="apiButton apiButton-module-MODULE_NAME apiButton-action-ACTION_NAME" - obviously a bit ugly... but manageable straightforward way to go about htis.

3) Are there any alternatives to making my api requests more reusable/easier to read? It's the only way I communicate with php so it's very... very important this system is solid.

1) Whereas I somewhat agree with Marcel Korpel on using HTML5 data attributes, I think that using the markup explicitly presents a couple potential problems: first off you are exposing your API/backend internals to the end-user, which is never ideal and secondly its kind of volatile because it could be easily changed (firebug, js) and mess up the behaviour associated with that element.

2) The more elegant (but slightly harder to implement method) would be to use jQuery's .data() method to store related information - this way you keep your markup clean and still have the flexibility of storing as much information as you want related to the element. It is also "hidden" from the end-user (sure firebug/js can access it but it's slightly harder to come by than right in the markup). There are basically 2 ways I can think of how you could implement this: -1 - if you are creating the markup dynamically then wrap the element in a jQuery object and apply the metadata before inserting it into the DOM or -2- if it is being created with PHP you could store it as a serialized string in "rel" or "rev" or someother little-used attribute and then use jQuery to grab it, store in metadata and clear the attribute.

3) However, now that I think about it, whereas using .data() is more elegant, I guess it doesn't make it all the more easier to understand because you are effectively hiding away applications internals. Perhaps you could implement getter/setters to retrieve the metadata or something along those lines.