Spelling suggestions: "subject:"ipi"" "subject:"tipi""
41 |
Katalogizace webových služeb založených na architektuře REST / Catalogization of RESTful webservicesKoch, Ondřej January 2011 (has links)
Currently there is a lot of enterprise middleware platforms based on SOAP-oriented webservices. However common message oriented middleware does not fully satisfy the need of integration small to middle sized services keeping the expenses reasonably low. The main goal of this thesis is to provide the analysis, and achitecture of a catalog for REST based webservices and to provide implementation at least for the purpose of practical examples. This catalog should enable it's users the publication of REST webservices, their categorization, searching, sharing and providing metainformation and therefore providing support for the deployment process, propagation, maintanance and further development and therefore lead to higher standarization of these services. The system should be percieved as a proof of concept of support system of a RESTful MOM.
|
42 |
Modulární webové rozhraní využívající MikrotikAPI / Modular web-based interface using MikrotikAPIJanda, Lukáš January 2016 (has links)
This diploma thesis is dealing with creating a web interface for managing and configuring RouterOS system using MikroTik API. Web interface is protected against intrusion unauthorized persons and contains mechanisms for managing users. This web interface allows extend the application using modules, which can extend functions of this interface. PHP framework was used for for creating this interface, configuration of RouterOS can be stored in a MySQL database.
|
43 |
Mapeo de ejemplos de código fuente para dar apoyo en el uso de APISAcurana Flores, Yasett Gisela January 2017 (has links)
Magíster en Tecnologías de la Información / Los desarrolladores de software con frecuencia recurren a Interfaces de Programación de Aplicaciones (APIs) para extender la funcionalidad de sus programas. El uso de APIs, que son un conjunto de reglas y convenciones mediante las que un programa puede comunicarse con otro, puede ocasionar defectos en el código fuente, como por ejemplo: defectos funcionales y/o de rendimiento.
Cuando un desarrollador desconoce el uso de una API, desea aprender más sobre su uso, o su código fuente no funciona como espera, busca manualmente ejemplos de la funcionalidad provista por la API. Esta tarea puede consumir mucho tiempo y ser propensa a errores. Por ejemplo, cuando inserta en su código la invocación a un método sin conocer bien los parámetros que debe enviar y luego el método no retorna el resultado esperado.
En la presente tesis se propone apoyar a los desarrolladores mediante la sugerencia de ejemplos de buen uso de las APIs. Los ejemplos son presentados en orden de relevancia, de acuerdo al código que están escribiendo los desarrolladores que usan la API. La implementación de esta solución consiste en la construcción y uso de un repositorio de ejemplos de código fuente, junto a un plug-in creado para el entorno de desarrollo Eclipse. El plug-in realiza la búsqueda de ejemplos del repositorio, muestra los ejemplos por orden de mayor a menor similitud y permite integrar el código fuente de un ejemplo en el editor de código fuente.
La utilidad de la herramienta ha sido validada por medio de un estudio con usuarios, donde se evaluó que el plug-in ayuda a desarrolladores con poco conocimiento de una API a hacer un mejor y más rápido uso de éstas. A los desarrolladores se les asignó dos tareas de programación para completar, una de ellas utilizando el plug-in y la otra mediante la búsqueda de ejemplos en Internet. Como resultado, se encontró que los desarrolladores terminaron las tareas hasta un 66% más rápido cuando usaron el plug-in, respecto de la búsqueda en Internet, y en su código fuente no se encontraron casos de mal uso de las APIs.
En base a los resultados obtenidos, se concluye que, pese a que la técnica planteada tiene sus limitaciones, se pueden obtener buenos resultados con la solución propuesta en la medida que el repositorio contenga los ejemplos que el desarrollador necesita. Como uno de los siguientes pasos se considera importante lograr una mejor precisión en los resultados de la búsqueda de los ejemplos, para que esta solución sea de mayor utilidad a los desarrolladores.
|
44 |
Refaktoring portálu Curriculum Generator na single-page aplikaciStratil, Jakub January 2017 (has links)
Stratil J. Refactoring of web portal Curriculum Generator to single-page application. Diploma thesis. Brno: Mendel University, 2017. This thesis is documenting the refactoring process of web application located at web portal Curriculum Generator. The thesis contains analysis of the application status, which is the basis for a draft. The draft includes changes to be made during the refactoring process, a process of choosing JavaScript framework for the refactoring process and a draft of new API. The thesis continues with an implementation of the proposed changes and draft, using chosen technologies. The thesis ends with a description of the refactored application deployment process.
|
45 |
A Systematic Literature Review on the Methodologies for Detecting REST Antipatterns in RESTful APIsNeagu, Andrei January 2022 (has links)
Context: API growth is accelerating. RESTful APIs are gaining traction and are backed by major players. Extending the APIs commonly introduce antipatterns, which are bad solutions to problems. Objective: The purpose of this review is to identify and analyze the current, state-of-the-art approaches in detecting antipatterns in RESTful APIs. Method: Six research questions are clearly defined. Search strings are used in digital libraries to identify studies in the field of antipatterns in RESTful APIs. The studies must come from reputable sources. Studies are subjected to inclusion-exclusion and quality assessment. Results: Eight studies were selected. Each study has one main approach. Three classes were created to identify the types of approaches. All approaches require expert domain knowledge to apply and vary in the difficulty of application. The accuracy of the approaches is above 80\%. Four types of antipatterns were identified and the approaches detect one or multiple types of antipatterns. Conclusion: Various techniques were discovered, each selected study presented a single technique. Classifications for the techniques and antipatterns were made. The research field is young with future work planned.
|
46 |
Facilitating the adoption and use of the IP Multimedia SystemPapazafeiropoulos, Christos January 2009 (has links)
The IP Multimedia Subsystem (IMS) is still under development and not widely adopted in the market. Some companies are reluctant to deploy IMS and some telecommunications vendors believe that IMS will not achieve a desirable market share. The purpose of this thesis work is to give a boost to this technology (i.e., to accelerate its market growth) by providing the community (both developers and operators who might adopt this technology) with an evaluation of the Ericsson Java Application Programming Interfaces (APIs) called Mobile Java Communication Framework (MJCF) APIs. Developers with or even without knowledge of the IMS architecture and signaling should be able to use these interfaces in order to develop applications on top of IMS. A client-server application is designed and implemented to facilitate this evaluation and to serve as an example for others. The motivation behind this application is the every day needs of the people who search for discounts while they are shopping. Users set up their profile by specifying their preference concerning discounts for specific products; while shop owners publish discounts. When a user is near a store which offers interesting discounts (i.e., discounts that match their profile) new notifications will be sent to his/her mobile device. This application exploits the MJCF APIs and uses several of its basic functions; specifically subscriptions, messages, notifications, and publications are some of the messages that can be utilized through these interfaces.</p> Throughout the application development, bugs were found in the APIs and corrections were suggested for the documentation. Measurements were made in order to evaluate the memory utilization and delay associated with these APIs. It was observed that the delays added by the APIs are somewhat high and may negatively affect the experience of users. However memory utilization seamed to be low for client applications and quite high for the server side given the resources of today's services and cellular phones. / Systemet IP Multimedia Subsystem (IMS) är under utveckling och är inte vida etablerat än. Nogra företag tvekar inför etablering av IMS och nogra telekomföretag anser att IMS inte kommer uppnå önskad marknadsandel. Syftet med detta examensarbete är att ge denna teknologi en skjuts framåt (d.v.s. att öka marknadstillväxten) genom att tillhandahålla den gemenskap av både utvecklare och operatörer som kan tänka sig ta in denna teknologi, med en utvärdering of Ericsson’s Java Applications Programming Interfaces (APIs) kallade MJCF API. Utvecklare med eller t.o.m. utan kunskap om arkitekturen och signalleringen hos IMS ska kunna använda dessa gränssnitt till att utveckla tjänster på IMS. En klient-server applikation är designade och implementerad för att möjliggöra denna utvärdering och för att agera exempel för andra. Motiveringen bakom denna applikation är det vardagliga behovet hos människor som söker efter rabatter/erbjudanden när de handlar. Användare sätter upp sin profil genom att specificera sina önskemål angående erbjudanden för specifika produkter medan butiksinnehavare publicerar sina erbjudanaden. När en användare är nära en butik som erbjuder någonting interessant (d.v.s. produkter som matchar använadarens profil), så kommer nya notifikationer att anlända till hans/hennes mobil. Denna applikation uttnyttjar MJCF APIet och använder ett flertal av dess basala funktioner; speciellt gällande prenumerationer, meddelanden, notifieringar och publiceringar är några av de meddelanden som möjliggörs genom dessa gränssnitt.</p> Genom applikationsutvecklingen så blev flera buggar i APIerna upptäckta och förbättringar till dokumentationen föreslogs. Mätningar gjordes för att utvärdera minnesåtgången och fördröjningar associerade med dessa APIer. Det observerades att API fördröjningar är något höga och kan påverka användarupplevelsen negativt. Däremot verkade minnesåtgången vara låg på klientsidan och hög på serversidan, givet de resurser dagens tjänster och mobila telefoner förfogar över.
|
47 |
Communication with databases : Comparing GraphQL with REST / Kommunikation med databaser : Jämförelse mellan GraphQL och RESTShahwali, Ali, Mattsson, Lukas January 2022 (has links)
REST and GraphQL are the two dominant Application Programming Interface (API) architectures being used for communication with databases. They differ in a lot of aspects, and as such it is not immediately obvious which architecture is preferable. This thesis aims to shed some light onto this problem by exploring two aspects, developer experience, and performance. The method used to measure the developer experience was a case study, in which participants had to write code that communicates with a REST API and a GraphQL API and then answer questions that describe their experience communicating with both. To test the performance, a case study was done in which 5 different benchmarks were ran comparing the two. The results of the first case study show that GraphQL solutions were perceived to give a more overall picture of what is happening than REST solutions. REST was, however, viewed as easier to complete the tasks with. The results of the second case study show that a server that implements REST architecture has better performance during normal circumstances, but GraphQL shows better performance if data is being requested with specified fields. / REST och GraphQL är de två dominerande applikationsprogrammeringsgränssnitten (API) arkitekturerna som används för att kommunincera med databaser. De skiljer sig i många aspekter och därav är det inte uppenbart vilken arkitektur som föredras. Denna avhandling har som mål att reda ut detta problem genopm att utforska två aspekter, utvecklarupplevelsen och prestandan. Metoderna som användes för att mäta utvecklarupplevelsen var en fallstudie, där deltagarna fick skriva kod som kommunicerar med en REST server och en GraphQL server och sedan besvara frågor som beskriver deras upplevelse med att kommunicera med dessa. För att testa prestandan gjordes en fallstudie där 5 olika benchmarks kördes för att jämföra de två servrarna. Resultatet från våran första fallstudien visar på att GraphQL ansågs ha en bättre helhetbild av vad som händer gentemot REST, men när det kom till själva implementaionen av uppgifterna, ansågs REST vara lättare. Resultaten av den andra fallstudien visar att REST arkitekturen har bättre prestanda under normala omständigheter, men att GraphQL har bättre prestanda när datan efterfrågas med enbart specifika fält.
|
48 |
An Empirical Study of API Breaking Changes in BioconductorChowdhury, Hemayet Ahmed 10 January 2023 (has links)
Bioconductor is the second largest R software package repository that is primarily used for the analysis of genomic and biological data. With downloads exceeding millions in recent years, the widespread growth of the repository's adoption can be attributed to it's diverse selection of community-created packages, written in the programming language R, that allow statistical methodologies for analysis and modelling of data. However, as these packages evolve, their APIs go through changes that can break existing user code. Fixing these API breaking changes whenever a package is updated can be frustrating and time-consuming, especially since a large fraction of the user community are researchers who do not necessarily have software engineering background. In that context, we first present a tool that can detect syntactic API breaking changes between two released versions of a library written in R through static analysis of the package source code. This tool can be of utility to R package developers, so that they can more comprehensively report or handle the breaking changes in their releases, and to R package users, who want to be aware of the API differences that may exist between two releases before upgrading the libraries in their code. Through the use of this tool and manual inspection, we also conducted an empirical study of the breaking changes and backward incompatibility in Bioconductor packages. We studied the 100 most downloaded packages in the repository and found that 28% of all packages releases are backward incompatible. We also found that 55% of these breaking changes go undocumented and developers don't maintain semantic versioning for 22% of the releases. Finally, we manually inspected 10 library releases that consisted of breaking changes and found 2% of the API-s to affect 31 client projects. / Master of Science / Bioconductor is a software repository that consists of over 2000 software libraries. These libraries can provide users with reusable functions, or APIs, to perform statistical and graphical data analysis. The developers of these libraries will generally make timely updates to the library source code and the functions for various maintainability purposes. However, when clients install these library updates in their existing code, their code might not compile, run or behave the same way it used to anymore due to the changes made in the APIs of the libraries. Such a library release that consists of changes that can potentially break older code is considered to be backward incompatible. Without proper documentation from the library developer's side, fixing these issues can be time consuming as the client might have to manually look at the changes made in the library's source code. In order to tackle this issue, we first present a tool that can analyse two versions of a library and identify a subset of the breaking changes in the API. This can be helpful for both the users and the developers of the libraries to be aware of any breaking changes that exist in a new release. Afterwards, we conduct a study on the Bioconductor ecosystem to see how serious the problem of backward incompatibility really is by studying the top 100 most downloaded packages from the repository. We see that 28% of the releases across these 100 packages are backward incompatible.
Since clients are likely to be using multiple libraries at once, this figure can potentially cause frequent issues in client code. We then go on to check how often developers maintain the correct release protocols when updating their libraries. These include versioning the releases in correct ways, so as to let the users be aware of what releases may be backward incompatible and documenting any breaking changes that occur in a NEWS file that users have access to. In that aspect, we find that 22% of the releases are not versioned correctly and roughly 55% of the breaking changes in the API are not documented. Finally, we investigate how frequently these breaking changes can actually affect client code. Here, we manually inspect 10 releases with a high number of a subset of the breaking changes and find 31 projects that implement these APIs, which would break upon a library update.
|
49 |
Avaliação do desempenho de busca de imagens por conteúdo em redes de computadores: uma proposta de reengenharia com aplicação a imagens médicas / Performance evaluation of images by content search in computer networkingOliveira, Fabio Brussolo de 27 February 2012 (has links)
O objetivo deste trabalho é avaliar a recuperação de imagem por conteúdo (CBIR - Content-based Image Retrieval) em uma rede de computadores, estabelecendo-se métricas de controle que otimizem a utilização da rede e ao mesmo tempo garanta melhor qualidade na resposta. Prevê-se a recuperação de imagens baseada em consulta por similaridade, combinando-se o extrator de características com a função de distância. O desenvolvimento é realizado em uma linguagem de programação independente da plataforma e de âmbito de internet, utilizado Java, desenvolvendo-se uma API (Application Programming Interface), visando, em especial, a reutilização de código, o que implica na diminuição do tempo de desenvolvimento. O trabalho demonstra a utilização de estruturas de indexação sequencial, comparada com a estrutura de indexação de árvore \"Slim-tree\". A principal contribuição deste trabalho é a análise e a utilização de métricas na rede de computadores em um projeto de CBIR. / The objective of this study is to evaluate the Content-based Image Retrieval (CBIR) in a computer network, establishing control metrics that optimize the use of network while ensuring better quality in the response. It is expected that images are going to be recovered based on queries that are similar, combining the features extractor with the distance function. The development environment is an independent language of the platform and of the Internet scope, using Java, that has developed an Application Programming Interfaces (API), aiming primarily the code reuse, which implies a decrease in the development time. This thesis demonstrates the use of sequential indexing structures compared to the tree index structure \"Slim-tree\". The main contribution of this thesis is the analysis and utilization of metrics in a computer network project in CBIR.
|
50 |
Web-based mapping : An evaluation of four JavaScript APIsNäslund, Magnus January 2008 (has links)
<p>As a result of Web 2.0 technologies such as Asynchronous JavaScript and XML (Ajax) web-based applications with rich contents are evolving to be more and more like normal applications in aspects, such as interactivity, functionality, and usability. This evolvement makes it possible to create web-based services, providing maps for users to search and browse geographic information. This thesis is an evaluation of functionality, usability and accuracy for the four web-based map APIs: Google Maps, Microsoft Virtual Earth, Multimap and ViaMichelin.</p><p>The thesis explains how web-based mapping works, common functionality provided, and evaluates the functionality provided by each map service provider as well as the offered usability. In addition to this, it also includes the results of several tests, illustrating the APIs’ browser compatibility, performance and accuracy.</p><p>After testing and evaluation of the four APIs, the conclusion is that none of them can be appointed as the winner. They all have benefits and drawbacks; differences in terms of functionality, compatibility, usability, geocoding and development support, and the choice of API is consequently dependent of the type of application. As a result of this, and the fact that the APIs are constantly changing in terms of functionality and coverage, it is important to create applications independent of the map service provider. This was successfully done during the internship at Amadeus by creating a map abstraction layer in-between the applications and the maps, creating the possibility to switch API, or map service provider, without changed the code.</p>
|
Page generated in 0.0554 seconds