February 20th, 2017, 03:56 AM
How to structure an API?
sorry to hijack this thread - do you have any resources on how to build a good api? I am not talking about the code but how to structure the endpoints
February 20th, 2017, 04:12 AM
That's okay, I can fix it.
Originally Posted by shez1983
Depends on the API. Really. What it does, how it's going to be used, who is going to use it...
But to answer the literal question, no. I suggest looking at similar APIs to see what they did.
Comments on this post
February 20th, 2017, 08:35 AM
sorry - i thought it was the similar type of thread so it was me not trying to create a duplicate thread. (i wasnt trying to be lazy, thought it may help the OP as well)
well i have been looking at tutorials and some lectures etc - but mostly they offer same type of examples (simple ones & crud type only) - no relationship type ones ie Trainer/Products or User/products/images etc , and how to organise data and
i have learnt quite a bit - but still am looking at ways to improve my code
February 20th, 2017, 02:52 PM
Trial and Error. I would try to keep things simple. No need to have a complex API. For examples, check out Google's and Facebook's API system. Fairly straight forward.
February 20th, 2017, 05:43 PM
Shopify has the simplest (but very impressive) API I can think of that is used by a very large company if you want an example.
APIs are a way to do things with other things. Literally, they're Application Programming Interfaces. This is a fancy way to say "a provided way to do a specific thing." Now, how many ways are there to do something?
Plenty. There are variations in protocols (HTTP vs SSH vs POP3), data formats, TCP vs UDP (EtherNet/IP, linked below, uses UDP), etc.
For how you transport your data, you got SOAP, you got RPC (I've heard arguments that SOAP is an example of RPC, but just as many arguments against that idea), you got COBRA, you got REST, you have EtherNet/IP (tho I haven't seen it used outside of PLCs).
For data formats you have JSON, XML, Protocol Buffers which is more commonly used than people think.
So, where does this put you?
Well, right now, REST over HTTPS with JSON is the de facto standard. Of course, SOAP over HTTPS with XML was also very popular before REST took over.
But does this mean it's right for you? Depends on what you're doing. I've implemented UDP Modbus APIs because it fit the situation better than any others.
In REST, those can be what's called "resources": specific types of documents. In your example, you have a resource you access via "/api/v1/users" (for example). If you want all the products of a user with key=1, you access "/api/v1/users/1/products." In this example, "products" is called a subresource of "users".
Integrate with as many APIs as you can in any many ways as you can. Amazon's Markeplace Service is lacking an up-to-date (or good) integration library. Maybe give that a try. MailChimp recently (ish) released v3 of their API, and I bet a lot of people would love to just drop in a dependency. UPS and Stamps.com lack an integration worth a damn.
Last edited by oakleaf; February 20th, 2017 at 06:13 PM.