I like to document my API (REST with JSON) which is written in PHP with the Symfony2 Project. This means I would like to write a public API, which I can give out to my clients, without showing them my internal functions etc.
What is the best practice to write Documentation in the public functions (Controllers, etc...). I'm currently using YAML for routing, which seems to be incompatible with the Annotation Based PHPDoc.
Thank you in advance!
You should then use NelmioApiDocBundle which was designed specifically for the need of documenting Restful Symfony2 API(s).
Find the bundle's documentation here.
It provides an ApiDoc() Annotation for Controllers,
The ApiDoc() Annotation.
And it also allows you to browse the whole documentation through an interfactive web interface,
On-The-Fly Documentation - Web Interface.
Related
Can anybody tell me where can I see a documentation for the sharepoint rest api ? I would like to see documentation like swagger has e.g. endpoints + dto objects. I need to make an integration with sharepoint to have CRUD functional for files. On Microsoft I see an articls that describe how to use it, but can`t find concrete list with endpoints and data tansfer objects.
Here the official Microsoft documentation : SharePoint REST service,
Please read all the part in the left navigation :
Bonus : Also, if you are a beginner and you want to start with SP API, I recommend you to use SP Insider extention, it is a free SharePoint Discovery tool for Developers. It allows you to explore the endpoint in an intuitive way and build your Query easily.
Cordially.
I need to use multiple APIs from multiple sources in my new website. They are all similar in functionality but with some differences in format. Then I need to build some type of proxy to make them all the same before use.
Can I use an API Management solution like WSO2 to integrate all these APIs and standardize them as a single API?
Is there another solution for this?
Thanks
You are actually looking for an integration solution. Therefore, what suits best is the WSO2 Enterprise Integrator. You can write a couple of Synapse code to combine a set of APIs and expose them as one.
Now, if you need to enforce policies such as authentication, authorization, rate-limiting etc. (i.e. if you need to expose this API as a managed API), then only you need APIM in front of it.
Kloudless provides an abstraction layer via a single unified API to connect to several third-party APIs without having to implement code for each of them. In that way, it functions as a proxy for all those third-party APIs and abstracts out data models, authentication, error-handling and rate-limiting, and more. (I'm a co-founder)
Use Wso2 Enterprise Integrator where You can create API and Apply the various integration patterns to achieve your requirement. Then if you need you can publish the same in API management.
ESB requirement:
You can use either a management console for creating API's or an eclipse designer extension from wso2. For creating API's XML knowledge is enough otherwise it also provides drag and drop feature.You don't require JAVA knowledge as the inbuilt mediators which are shipped with Wso2 ESB is enough. But if you have knowledge of java then you can create custom meditaors(mediators are used for creating busniess logic) incase of some special needs. If you don't know JAVA then you can use Javascript, Ruby, Groovy inside script mediator. I prefer for smaller transformation I will use Script mediator if you have larger message size then you can go with class mediator that's where we'll use JAVA. This is all the requirement you need for ESB.
Technologies required for ESB: XML, XPATH, JsonPath, XSLT, Xquery , scripting knowledge(Javascript, Ruby, Groovy)etc.
If you are beginner then please refer this tutorial https://docs.wso2.com/display/EI640/Integration+Tutorials
For API management programming knowledge not required.
I am new to web dev but I have managed to build my site using GWT and GAE. I use RequestFactory for client-server communications.
Now, someone wants to make mobile applications that use my backend.
I have found that RequestFactory works very well with Android. But I am somehow afraid it will not work with other "not-google" front ends (iOS for instance).
So my question is, can I make an API based on my RequestFactory backend (servlet) that can be used by any client? Any initial pointers as to how to implement it would be appreciated.
I guess technically it would be possible. However, if you want to create an api anyone can use, you probably want an api were you specify both how to communicate with the api and the content send/received by the api. With RequestFactory both the how and what is shielded by RequestFactory. So if someone wants to communicate with your api and can't use the RequestFactory code in the project, the how and what of RequestFactory must be reverse engineered, and could change anytime because it's not guaranteed. Not the most elegant way to go forward.
A better approach is define an open api were you specify the how and what. For example with
and apu based on REST (the how), communicating JSON data, and to specify the content format (the what). An example of such an api is the twitter api.
For your own project you could build on your api also, for example by using RestyGWT. Then you don't have to maintain both the code for the RequestFactory interface and REST interface. For other platforms there are probably several libraries available to make developing against a REST interface easy.
I need to control who or what role gets access to what page or what method. Something like the class and method anotations on ASP MVC or Spring JAVA.
How can I do this in lithium?
There is no built-in complete ACL functionality on Lihtium's core, beauce there is no really solution to ACLs problem.
Hopefully, Lithium is kick-ass when it comes to deal with external libraries and plugin to extend the core functionality.
Take a look to li3_access which is the most complete and flexible plugin or ACL out there, or simpler solutions.
If your only need is to specify which actions are public and which not, you can dot it using Lithium filters: Read the guide
PS: Zed Shaw - The ACL is Dead http://vimeo.com/2723800
I have a "thin" (SOAP) API that only knows how to set and get entities in the underlying system.
I am about to to create a "rich" API that encapsulates the "thin" API and implements the logic that is required for complex operations that entail getting and setting several entities in specific order.
Example: The rich API will be responsible for creating a new user account by creating a "Lead" entity that's linked to an "Account" entity via the thin API.
I'm stuck in a naming block so I turn to SO ;) What name would you give my rich API? "xxxRichAPI"? "xxxHelper"? "xxxService"?
Isn't the point of an API that it hides it's implementation? As such, the fact that your API calls a thinner API is irrelevant. Name your API appropriately for what it does, regardless of how it does it.
At first glance, this sounds like the GoF Facade pattern to me. You might considering using the name "xxxFacade".