If you are new to the Spire API, it's useful to have a platform from which to assemble and try examples. People all have different learning strategies. This document tries to approach the API by providing a means to execute examples, and see their results. This can be challenging, because API use generally involves some degree of development effort, and the tools, languages and frameworks vary in complexity and there are many of them. The goal here is to provide some level ground from which to build knowledge and facility with the API.
This example uses a free application called CURL. It's a generically used, freely available command line application. With it, you can do everything that the Spire API browser (the web based way of accessing the Spire API) can do (and a lot of things it cannot). For reference, Spire QA uses this tool, and many API examples in order to build companies and setup test data for test automation. It's fast, relatively easy to use, and it removes the complications of discussing the plumbing of other tool chains and languages. Even if your goal is to write a complex, object oriented, compiled application this topic is a good place to start. All the examples in this topic and in the rest of the forum can be tested and experimented with using Curl.
Note that a prerequisite before beginning is that the Spire application and server be installed, and that there be a known url where you can access a Spire company. Ideally, you can login to this company and work back and forth between the Spire desktop user interface, and the API. This is really helpful for validating results (e.g. Did the part number I tried to created get created in the expected way). It's also important to mention the that Spire API honors the same constraints as the Spire user. If a user cannot, for example, access General Ledger resources, they will be blocked in the Spire API as well.
* Be aware that you can effect data with the Spire API, and this extends all the way up to and including deleting an existing company. Use care, and make sure you have complete backups before proceeding.
"localhost" basically means "this machine". You can replace the Url with your ip address, a server name or the allocated Spire hostname. A hint here - If you logon to Spire desktop and choose "Tools, Spire Server Administration" you will be re-directed to the correct Url.
A couple of key concepts
Rest API's use a small number of HTTP verbs. POST is generally used on a collection in order to create a new resource. PUT is generally used to update or change an existing resource. You normally use a PUT verb on an endpoint (rather than a collection).
Collections are are expressed to the Spire API as groups of records. The following is a collection;
Endpoints represent a specific resource. The following is an endpoint;
Notice the the presence or absence of a forward slash determines whether a url is addresses as a collection or and endpoint. In the above example, the url points to a specific part number with the ID of "1".
Structuring Json can be a challenge when you are doing it by hand. Note that generally in larger applications you will use tools to help you with this. Ultimately some kind of object model is often build to map your data to Spire expectations. That is beyond the scope of this discussion, but it's useful to be aware of this.
There are a number of other examples in this forum that should be easily adapted to the example provided here.