aclindsa/ofxgo
1
0
Fork 0
mirror of https://github.com/aclindsa/ofxgo.git synced 2024-11-22 11:30:05 -05:00
Code Issues Releases Wiki Activity

Cleanup documentation

Browse Source
This commit is contained in:
Aaron Lindsay 2017-04-10 20:51:02 -04:00
parent be66031c49
commit d6aa6608e7
1 changed files with 43 additions and 40 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

83
doc.go
View File

@ -3,17 +3,17 @@ Package ofxgo seeks to provide a library to make it easier to query and/or
parse financial information with OFX from the comfort of Golang, without having parse financial information with OFX from the comfort of Golang, without having
to deal with marshalling/unmarshalling the SGML or XML. The library does *not* to deal with marshalling/unmarshalling the SGML or XML. The library does *not*
intend to abstract away all of the details of the OFX specification, which intend to abstract away all of the details of the OFX specification, which
would be very difficult to do well. Instead, it exposes the OFX SGML/XML would be difficult to do well. Instead, it exposes the OFX SGML/XML hierarchy
hierarchy as structs which mostly resemble it. For more information on OFX and as structs which mostly resemble it. For more information on OFX and to read
to read the specification, see http://ofx.net. the specification, see http://ofx.net.
There are three main top-level objects defined in ofxgo. These are Client, There are three main top-level objects defined in ofxgo. These are Client,
Request, and Response. The Request and Response objects, predictably, contain Request, and Response. The Request and Response objects represent OFX requests
representations of OFX requests and responses as structs. Client contains and responses as Golang structs. Client contains settings which control how
settings which control how requests and responses are marshalled and requests and responses are marshalled and unmarshalled (the OFX version used,
unmarshalled (the OFX version used, client id and version, whether to indent client id and version, whether to indent SGML/XML elements, etc.), and provides
SGML/XML elements), and provides helper methods for making requests and helper methods for making requests and optionally parsing the response using
optionally parsing the response using those settings. those settings.
Every Request object contains a SignonRequest element, called Signon. This Every Request object contains a SignonRequest element, called Signon. This
element contains the username, password (or key), and the ORG and FID fields element contains the username, password (or key), and the ORG and FID fields
@ -25,39 +25,42 @@ and Message fields populated by the server, or the CodeMeaning() and
CodeConditions() functions which return information about a particular code as CodeConditions() functions which return information about a particular code as
specified by the OFX specification). specified by the OFX specification).
Each top-level Request or Response object may contain zero or more Messages, Each top-level Request or Response object may contain zero or more messages,
represented by a slice of objects satisfying the Message interface. These sorted into named slices by message set, just as the OFX specification groups
messages are grouped by function into message sets, just as the OFX them. Here are the supported types of Request/Response objects (along with the
specification groups them. Here is a list of the field names of each of these name of the slice of Messages they belong to in parentheses):
message sets (each represented by a slices) in the Request/Response objects,
along with the concrete types of Messages they may contain:
Signup: Requests:
AcctInfoRequest/AcctInfoResponse: A listing of the valid accounts for this login var r AcctInfoRequest // (Signup) Request a list of the valid accounts
// for this user
Banking: var r CCStatementRequest // (CreditCard) Request the balance (and optionally
StatementRequest/StatementResponse: The balance (and optionally list of // list of transactions) for a credit card
transactions) for a bank account var r StatementRequest // (Bank) Request the balance (and optionally list
// of transactions) for a bank account
CreditCards: var r InvStatementRequest // (InvStmt) Request balance, transactions,
CCStatementRequest/CCStatementResponse: The balance (and optionally list of // existing positions, and/or open orders for an
transactions) for a credit card // investment account
var r SecListRequest // (SecList) Request securities details and prices
Investments: var r ProfileRequest // (Prof) Request the server's capabilities (which
InvStatementRequest/InvStatementResponse: The balance and/or list of // messages sets it supports, along with features)
transactions for an investment account
Securities:
SecListRequest/SecListResponse: List securities and their prices, etc.
SecurityList: The actual list of securities, prices, etc. (even if
SecListResponse is present, it doesn't contain the security information). Note
that this is frequently returned with an InvStatementResponse, even if
SecListRequest wasn't passed to the server.
Profile:
ProfileRequest/ProfileResponse: Determine the server's capabilities (which
messages sets it supports, along with individual features)
Responses:
var r AcctInfoResponse // (Signup) List of the valid accounts for this
// user
var r CCStatementResponse // (CreditCard) The balance (and optionally list of
// transactions) for a credit card
var r StatementResponse // (Bank): The balance (and optionally list of
// transactions) for a bank account
var r InvStatementResponse // (InvStmt) The balance, transactions, existing
// positions, and/or open orders for an
// investment account
var r SecListResponse // (SecList) Returned as a result of
// SecListRequest, but only contains request
// status
var r SecurityList // (SecList) The actual list of securities, prices,
// etc. (sent as a result of SecListRequest or
// InvStatementRequest)
var r ProfileResponse // (Prof) Describes the server's capabilities
When constructing a Request, simply append the desired message to the message When constructing a Request, simply append the desired message to the message
set it belongs to. For Responses, it is the user's responsibility to make type set it belongs to. For Responses, it is the user's responsibility to make type