API?

[mudmin]

I've had a few requests over the years for a UserSpice API. I haven't really known what to say when it comes to something like that because it's such a broad term and I can't think of one particular use case that everyone needs and you absolutely do not want an open API where people are hammering on your db if you don't know what you're doing.

Thoughts?

I've thought about showing people how to just write their own. My primary use case for mine is connecting my separate products together. I have a point of sale system based on UserSpice. I also have a camp registration system based on UserSpice. I need my point of sale to reach out to the camp registration system, see if the camper whose RFID wristband was scanned has enough money in their account to complete the purchase and if they do, subtract the money, record the transaction, and make the purchase.

Again...that's a super custom use case. Some people may want their users to have a limited number of API requests. Some might be server to server like mine. I'm just not finding that common scenario that I can build a generic API around.

My only thought was to add a table of tables in the db and if the table is in that list, it can be queried by the API. Maybe a second table of excluded fields like users->password. That's about all I can think of.

[Brandin]

See - to me - in your case - I would just be using the customer DB classes (DB2, DB3) etc...but this could get messy depending on the amount of connections you need.

E.g. previously I needed to connect my system called Templates to BOSS, so in Templates you made a class for me called DB2 and whenever I needed to query the BOSS database, I just did DB2. Vice versa for BOSS to Templates.

I think the only other thing I might use an API for is oAuth between two US systems - but then again - I could just use DB2 again...

[mudmin]

The problem is that even though they're my projects different people have different code on their servers. So, the pos is locally hosted and the registration system is on my remote server. The people who have the POS can look at the source code and would have access to the db creds. The API severely restricts what kind of queries they can make and who can make them.

[karsen]

These might be good starting points:
Simple- https://github.com/mevdschee/php-sp-api
Complex- https://github.com/mevdschee/php-crud-api

[mudmin]

Yeah. The simple one is a lot closer to what I wrote. I think it's good practice for someone to think through how they want (and don't want) their API to be used... which is why I think it would make for a good course.

I think either way, I'm going to add the function(s) to call other APIs. So all userspice installs will be able to make relatively simple CURL requests with very little coding...It's just a matter of if they will receive requests.