ebay como interface API para um portal web
https://stackoverflow.com/questions/1231532
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPergunta
Temos desenvolvido um portal Web B2B para trabalhos gráficos trabalho que é semelhante ao visor da câmera de Arte (www.camerareadyart.com). Ele é voltado para pessoas que desejam bitmap convertido para gráficos vetoriais, logo design e processamento de imagem geral, como coloração B / W imagens de cor, etc.
Queremos adicionar facilidade para que as pessoas (nossos clientes) pode usar um conjunto de API que nós fornecemos para postar seus trabalhos a partir de seu site diretamente sem ter que visitar o nosso site, literalmente, para deixar seu trabalho.
Eu nunca fiz nada parecido com isso até agora, por isso tenho nenhuma idéia de como eu pode implementar algo parecido com isso. Eu também quero saber sobre como podemos implementar a segurança para que apenas aqueles que estão autorizados podem postar seus trabalhos?
Alguém pode me dar idéias de como podemos fazer algo assim.
Solução
Esta questão cobre uma área muito grande e eu duvido que qualquer resposta única poderia cobrir assuntos detalhadamente. O que posso fazer é oferecer alguns pontos de partida com base nos erros que cometi.
Desenvolver a parte superior de seu próprio API
Não adicionar funcionalidades de API para um sistema existente. Se o fizer, será:
- levar a carga de testes adicionais (você vai ter que teste tanto a sua aplicação e a API de forma independente)
- resultado em um aumento nos custos gerais de manutenção
- resultado em uma API pior qualidade do que o que você quer oferecer
Seu objetivo geral deve ser construir a API em primeiro lugar e, em seguida, construir a sua aplicação em cima de sua própria API. Se o fizer, tem os seguintes benefícios:
- teste do API é inerentemente realizada enquanto testando o aplicativo
- você não vai 'esquecer' para adicionar quaisquer métodos API necessários
A sua aplicação e sua lógica de aplicação (API) serão separadas logicamente - haverá uma separação clara entre eles em termos do que cada lado da equação faz eo que é responsável. Isso ajudará a guiar o desenvolvimento. Isso também irá permitir que você coloque muito, muito facilmente o aplicativo e o API em máquinas diferentes como e quando isso é necessário.
Usando sua própria API é um ponto muito importante. O design do seu API será inicialmente sub-óptima e só através de usá-lo se você vai ser capaz de fazê-lo oferecer às pessoas os recursos que são realmente necessários de uma forma que seja eficiente.
Você vai acabar com um sistema que cerca de parecido com este:
------------- -------------
| | | |
| Your APP | <= HTTP communication => | Your API |
| | | |
------------- -------------
Isso destaca alguns benefícios adicionais: você pode substituir 'Your APP' com qualquer outro aplicativo, permitindo que os clientes de seu para criar aplicativos para lidar com as coisas de maneiras que o trabalho com eles melhor. Você também pode criar novas versões do seu aplicativo no topo da API existente -. Movendo-se para uma nova versão do seu site público pode ser muito mais fácil
Projetando suas URLs: mapeamento para classes e métodos
Escolhendo URLs sensatas é tanto de um problema como escolher nomes de classes e métodos sensíveis. Derivando URLs de classes e seus métodos é uma boa abordagem. Se não existe uma correlação razoável entre URLs e classes / métodos, você vai encontrar as coisas mais difíceis para manter a longo prazo.
Eu pessoalmente prefiro a URLs associados a classes e métodos das seguintes formas:
- mapa aulas para os diretórios de nível superior
- mapa métodos para sub-diretórios dos diretórios de nível superior
Exemplo:
O URL do seu API é https://api.camerareadyart.com .
Você tem um objeto image com métodos toColour() e toBlackAndWhite().
Isto pode mapear para:
https://api.camerareadyart.com/image/toColour/
https://api.camerareadyart.com/image/toBlackAndWhite/
Da mesma forma para bitmap para conversão de vetor:
https://api.camerareadyart.com/bitmap/toVector/
respostas Projetando
Quando alguém obtém dados de, ou postes de dados para, uma de suas URLs, o que acontece? Como são erros tratadas, como são exceções tratadas? Qual a forma de respostas tomar?
Eu não posso te dizer o que fazer aqui. Pessoalmente eu prefiro para mapear as coisas como de perto para HTTP quanto possível e só então ir além disso, quando necessário.
Por exemplo, se uma solicitação de entrada é aceita e é processada mas é executado em um erro internamente eu iria emitir uma resposta de estado 500. Da mesma forma, se um determinado método API requer autenticação que não tenha sido fornecido eu poderia emitir uma vantagem 403. Tomada de HTTP existente apresenta o impede de ter que re-inventar certas coisas.
Use aspectos da existente HTTP
Bem como a utilização de códigos de status HTTP de forma sensata, certifique-se de olhar ao redor para um método HTTP-only para fazer algo antes de rolar sua própria solução.
Quer o usuário para especificar se o formato de resposta deve por XML ou JSON? Use o cabeçalho HTTP Accept.
Quer re-direcionar um cliente para uma URL diferente para pegar o resultado de um pedido? Usaro cabeçalho HTTP Location.
Existem muitas características para HTTP que já lidar com muitas coisas que você pode querer fazer. Usá-los!
Segurança
Há dois problemas gerais para resolver aqui:. Autenticar o usuário, e determinar que as ações de um determinado usuário pode executar
Segurança: autenticação
O usuário precisa especificar no seu pedido que eles são.
A primeira solução para vêm à mente é permitir que o usuário especifique um nome de usuário e senha, possivelmente o mesmo que o nome de usuário e senha que eles usam para acessar seu aplicativo. Isto parece na superfície a ser uma boa idéia, mas não é ideal.
Os usuários irão acabar assar seu nome de usuário e senha em seus próprios aplicativos. Inevitavelmente um usuário vai esquecer sua senha e alterá-lo para que eles possam felizmente acessar seu aplicativo, quebrando seu próprio aplicativo no processo.
Uma melhor escolha seria para que o usuário forneça um token de autenticação, que é essencialmente um único valor único para um usuário muito parecido com um nome de usuário e senha em um só.
Isso permite separar logicamente um nome de usuário e senha de acesso à API. Um usuário pode mudar seu nome de usuário e / ou senha para a sua aplicação quantas vezes eles como sem quebrar o seu acesso à API.
Um usuário também pode ter vários símbolos da API, cada um com diferentes níveis de acesso, permitindo que um usuário para dar segurança para fora uma API token para um serviço de terceiros.
Segurança: controle de acesso
Tanto quanto o mundo exterior está em causa, a sua API é um conjunto de URLs. Cada URL é, por definição, única e executa uma tarefa única. Baseando seus mecanismos de controle de acesso em torno destes conceitos é um ponto de partida bom.
Eu prefiro manter uma lista, por sinal, das URLs que token é permitido o acesso. Quando um determinado token é usado para acessar uma URL é trivial dizer qual URL está sendo acessado e se é na lista do sinal de URLs permitidos.
Se você escolher um conjunto de URLs de forma inteligente, em que cada URL executa uma ação única, este processo proporciona-lhe sobre o melhor nível de controle de acesso, como você está indo começar.
Para dar um nível mais refinado de controle que você também pode querer especificar, por URL que um token é permitido o acesso, que argumentos consulta eles estão autorizados a usar.
Outras dicas
Você, obviamente, precisa ter seus webservices backend concebidos e de trabalho. No entanto, todos os recursos adicionais (segurança, otimização, gerenciamento de chaves OAuth, assinante portal, console interativo para experimentar as APIs, etc.) são um conjunto bastante normal de recursos que você provavelmente não deveria ser desenvolver-se.
Existem soluções de gerenciamento de API comerciais no mercado. Eu trabalho para WSO2, que tem um 100% open-source (Apache License) Gerente WSO2 API, que você pode baixar gratuitamente aqui ou uso como uma versão hospedada nuvem no WSO2 cloud API .
