PplWare Mobile

Tutorial: Criar API RESTful com autenticação em apenas 5 minutos (P1)

                                    
                                

Este artigo tem mais de um ano


Autor: Pedro Pinto


  1. VE Autónomo says:

    API’s com Javascript é que não! 🙁 o javascript pode ser uma boa ferramenta para o Frontend, mas sem dúvida que não é a melhor solução no que toca a backend. Têm PHP, Go, Python ou até mesmo Java. JS é que não.

      • VE Autónomo says:

        Não sei se se trata mesmo de gostos. Qualquer uma destas linguagens que disse, é mais matura do que o Javascript em termos de backend Sendo assim, sendo as outras opções mais maturas, são também mais seguras e mais eficazes neste tipo de tarefas. A execução dos requests também vai ser mais rápida, bastante mais rápida.

        Tem tudo a ver com a necessidade e de usar o mais correcto para a necessidade. Quando estamos a fazer mudanças de casas, não vamos usar o ferrari descapotavel para transportar o armário centenário da avó Lurdes, usamos uma carrinha ou algo maior. A mesma coisa aqui… para desenvolver uma api, um backend, deve-se usar algo que foi concebido para esse efeito, e não algo que foi martelado e criado para substituir algo sólido. Javascript no Frontend? Sim. No backend? Não, quando há soluções melhores.

        • jedi says:

          Desculpa la mas não concordo. Não vamos confundir JavaScript que corre no browser , que funciona como uma sandbox com a respetivas limitações ou restriçoes para o efeito, com NodeJS, que por baixo do capô tem o motor de JavaScript do Google Chrome , o V8 , sem a restricoes e com as mesmas capacidades de linguagem backend como PHP , C SHARP Ou Java .e quanto a performance nao fica nada a tras das outras se for bem feito, como tudo na vida.

          Quanto á segurança, se nao conheceres bem ou nao seguires as guidelines e standards de segurança daquela linguagem ou Framework, por mais segura que diga ser a linguagem encontraras sempre buracos. O exemplo disso é o facebook que utiliza PHP abundantemente e ultimamene tem tido ataques aos seus servidores a torto e direito. 😉

    • joaquim faria says:

      nao vejo qual o problema de usar node…

    • Pescador says:

      Epa, por acaso lá em cima diz que nodeJS é uma linguagem de programação, primeiro erro grosseiro.
      E depois, por acaso, JavaScript como backend é qualquer coisa de evitar.
      Mas também a tua solução, PHP? E dizeres “ou até mesmo Java”?
      Nem gosto de Java, mas em Portugal backend em Java é tão e somente o mais usado.

    • joao says:

      andas um bocado desactualizado…..

    • Tiago Soares says:

      PHP? Medo…

      • Mijn says:

        Quando não se sabe do que se fala diz-se disto… Todas as linguagens tem problemas, nenhuma é perfeita, e todas ou quase todas são capazes de fazer tudo… umas são mais adequadas do que outras. PHP é muito competente para este tipo de uso.

        • Tiago Morais says:

          E a sua resposta é de quem sabe do que se fala? Está certo.
          Pessoalmente também me mete medo quem usa PHP para uma API… atenção… para uma API. Há soluções mais rápidas, mais seguras e com muito mais funcionalidades que PHP.
          Agora… Consegue explicar porque é que o comentário do Tiago é proveniente de uma pessoa que não sabe do que fala?

          • PedroC says:

            Eu acho que é porque as pessoas quando estão atrás de monitores gostam de se insultar umas às outras. É basicamente o que eu vejo em todas, sem excepção, mesmo TODAS, as zonas de comentários 🙂

          • Tiago Morais says:

            Concordo Pedro. Algumas pessoas bem que podiam começar a perder esse tempo em fazer criticas construtivas em vez de tentar enxovalharem-se umas ás outras. Cumprimentos.

          • Gonçalo says:

            “Pessoalmente também me mete medo quem usa PHP para uma API”.
            Porquê?

        • Pescador says:

          Queres mesmo continuar num argumento que já perdeste à partida?
          PHP e competência na mesma frase é de quem percebe do assunto, é isso?
          E que competência é essa?
          Será que o teu argumento, sobre todas as linguagens aqui faladas se resume a serem Turing Complete?
          E achas mesmo que é esse o factor eliminatório?

      • Phablo says:

        O cara falando mal do PHP, prova o bom profissional que é.

      • lUiS says:

        Isso. Anda cerca de 80% da web errada e tu é que estás certo.

        • Pescador says:

          Portanto se muita gente usa é porque é bom, é isso? Portanto, muita gente usa software tipo Paint, portanto para quê usar programas CAD?! Esse é o teu melhor argumento sobre o uso de PHP?

          • João says:

            Trabalho profissionalmente todos os dias com APIs de grandes seguradoras e instituições de crédito, muitas delas desenvolvidas em PHP, e sem qualquer tipo de problemas de performance e segurança. Quem coloca à frente dos cuidados de segurança o escolha de linguagem que deve ser usada, não sabe nada do que está a falar. Já vi WebServices desenvolvidos com tecnologias diferentes (ASP.NET, NodeJS) que são um autêntico buraco. E trabalho com algumas APIs de PHP que nunca manifestaram qualquer problema de segurança. Os problemas não estão nas linguagens que se usam para o desenvolvimento. Está na forma como se aplicam as regras de segurança.

          • Pescador says:

            João, acho que concordas que Java é relativamente segura como linguagem, no entanto já tive a infelicidade de mergulhar os meus olhos em montanhas de linhas de código horrível, que da forma como foi feito, levava a uma serie de problemas, de potenciais falhas de segurança e mau funcionamento, e isto num projecto de uma multinacional, e que aparentemente era um software seguro.
            Podes ter um software de grande escala feito em PHP relativamente seguro, rápido e que seja possível de manter e alterar ou adicionar novas funcionalidades com alguma razoabilidade?
            Tenho as mais serias duvidas que consigas as 3 coisas ao mesmo tempo, porque para atingires as 2 primeiras, alem de precisares de ter muita disciplina, e claro que não trabalhas sozinho, portanto todos têm de seguir a mesma disciplina e os mesmos padrões, o código fica quase intratável.

      • Tiago Boeing says:

        Como não paro de receber notificações por ter comentado em resposta a outro usuário, entro na ‘discussão’. A real é que toda linguagem de programação tem suas vantagens e desvantagens, e sem dúvidas a melhor delas é a que você mais domina e consegue implementar com maior facilidade, você vai encontrar algumas limitações dependendo do que precisar, mas isso é normal, basta realizar um estudo prévio da melhor opção antes de sair desenvolvendo.
        Hoje em dia estudo bastante e utilizo Spring Boot e Node, mas PHP para API se utilizado com Laravel, por exemplo, não fica atrás não. É bem documentado, ‘tipado’ e está nos padrões das demais linguagens, já utilizei Laravel e é relativamente fácil, não sei qual o seu medo quanto a isso, talvez aplique-se apenas a criticar PHP sem muitos fundamentos.
        Já Node para backend, não tem problema algum, evoluiu bastante, atende as necessidades e tem uma produtividade bacana. Spring Boot você consegue gerar CRUDs de forma bem rápida, além de existir recursos/bibliotecas para praticamente tudo que necessitar, mas tudo é questão de escolha. Não tem essa de linguagem melhor ou pior, avaliem suas necessidade e escolhem o que considerarem útil, tudo varia do projeto. Essa discussão nunca vai ter fim, mas devemos procurar conhecer todas as linguagens antes mesmo de criticar.

        • Pescador says:

          Tiago, PHP tem problemas por muitos considerados graves do próprio desenho da linguagem. E se há coisa que PHP não é, é bem tipada. E isso cria problemas adjacentes a esse mesmo facto, e isto é só um exemplo do porquê de PHP não ser uma boa linguagem de programação.
          A tua introdução está inteiramente correcta, e há empresas que dispendem de tempo só para estudar linguagens e ferramentas associadas para perceber se são ou não boas de se usar em projetos. E claro, há aquelas empresas que vão na onda do que vêm outros a usar e que por acaso têm por lá programadores que sabem de tal linguagem e ferramentas, mas isso não é uma boa forma de escolher nada.
          O que afirmas no final, é uma meia verdade, porque dependendo do projecto, assim deve ser a escolha, correto, mas que há linguagens muito melhores que outras há. Porque para determinado projeto, há no mínimo sempre 3 ou 4 linguagens conhecidas e mais outras tantas menos conhecidas que qualquer pessoa pensa nelas, e todas elas podem satisfazer o objetivo, mas olhando apenas para o factor linguagem e suas ferramentas, há linguagens com sintaxe horrível, com problemas de desenho da própria linguagem que levam a erros do programador que mesmo com uma disciplina enorme vai sempre produzir erros porque a linguagem não o protege desses erros, aliás, algumas induzem a erros, a questão dos tipos é de vital importância, a questão de haver ou não haver mutação, se pode haver ou não mutação por todo o código, como se isola entao a “stateful logic” e a “view logic”, e por aí fora. Dando o exemplo de uma das linguagens mais usadas no mundo Java, o ecossistema é enorme, ferramentas para tudo, no entanto a linguagem em si é horrível, e em diversos aspectos.
          PHP, que é o que discutimos, apesar de ter tido muito uso pela NET, não é, para os padrões de hoje em dia, a primeira escolha para backend, nem a segunda escolha, nem a terceira escolha, nem a quarta nem a quinta, nem a sexta.

    • JL says:

      O NodeJS já amadureceu o suficiente para servir de alternativa. Tem bons ambientes de servidor que facilitam a implementação de serviços REST.
      Recentemente encontrei o NestJS (baseado em Express) que permite um trabalho mais progressivo e tem esquema parecido a Angular, além de usar Typescript.

    • José Maria Almeida Rainha de Oliveira Simões says:

      Fiquei na duvida. Poderia explicar porque razão não é boa ideia ? Quais os potenciais problemas ?

      • Pescador says:

        Por vários motivos, pode ser por uma questão de interoperabilidade com software já existente, pode ser por uma questão de escalabilidade, ou porque já há software bastante desenvolvimento, testado e usado em cenários específicos e que também são o nosso, pode ser porque se quer ter um controlo maior sobre os dados. Portanto, pode ser por uma carrada de factores.

        • Gonçalo says:

          – uma questão de interoperabilidade com software já existente
          lol
          – pode ser por uma questão de escalabilidade
          lol
          – já há software bastante desenvolvimento, testado e usado em cenários específicos
          lol
          – porque se quer ter um controlo maior sobre os dados
          lol

          são estes os teus argumentos para não se usar PHP?
          quem não sabe (não pesca do assunto) devia estar calado…

          • Pescador says:

            Se queres podemos falar especificamente de aberrações que se vêem em PHP.
            E o teu argumento é um lol?
            Portanto tu percebes do assunto porque sabes o significado de lol? Argumentos teus zero até agora.

          • Pescador says:

            Então o fanfarrão dos lols ainda não arranjou nada de espetacular na linguagem para argumentar? Tanto lol e argumentos zero, já lá vai um dia. Queres umas dicas ou safaste sozinho?

          • Gonçalo says:

            – uma questão de interoperabilidade com software já existente
            o php não comunica bem com outros “softwares”?
            – pode ser por uma questão de escalabilidade
            não consegues escalar software com php?
            – já há software bastante desenvolvimento, testado e usado em cenários específicos
            não existe software em php que esteja bastante desenvolvido, testado e usado em cenários específicos?
            – porque se quer ter um controlo maior sobre os dados
            com php não consegues ter controlo sobre os dados?

            não te quero convencer a usar o php, mas gostava de perceber o teu ponto de vista sobre o porquê de não usar o php, mas só vejo argumentos vagos sem fundamento.

    • Pedro says:

      Pedro, estou a responder pela positiva sem querer ofender ninguém, mas muitos têm criticado alguns títulos mais ou menos à moda do CM. A pplware tem que repensar essa questão…

  2. PedroC says:

    Tenho uma página em php e estou a obter dados de uma API. Queria no entanto que o meu frontend fosse updated com os dados dessa API em real time. Não sei sequer por onde começar visto que há agora tanta coisa. Alguém me consegue indicar um tutorial ou exemplo para o que pretendo? Obrigado.

    • Tiago Boeing says:

      Para realtime você precisa usar websockets, tanto no backend, quanto frontend, ambos abrirão um “túnel” de escuta por eventos. Em Node, React ou Angular, você usa uma biblioteca chamada Socket-io, em PHP, pesquise… Mas deve ter bibliotecas disponíveis.

  3. Guilherme says:

    C# MVC Web API em .NET Framework or ou então .NET Core

    enough said?

  4. Pedro H. says:

    Embora tenha a preferência pelo Altorouter em PHP isto parece interessante. +1 e fico a aguardar pela 2ª parte xD

  5. augustowebd says:

    o título fala 5 passos, quantos foram apresentados. programar requer interpretação de textos.

  6. jedi says:

    Peço desculpa mas tem de rever a parte “linguagem de programação o nodeJS”, porque não é uma linguagem. veja em https://nodejs.org/en/

    Segundo, nao sei se existe algum tutorial de NodeJS, mas deviam começar pelo basico de nodejs.

    Posteriormente, começaria pela framework expressjs e so depois falava de outras frameworks, como adonisjs que tem o flow semelhante a laravel.

  7. Joaquim Alcobia says:

    Para mim ws é java. E podes usar swagger na mesma para ficares assim com a documentação toda pipi…

  8. Gustavo Antonaci says:

    Olá turma, gostei do artigo mas concordo plenamente com o VE Autónomo, JS para back-end, na minha opinião é furada, pois esta linguagem não foi idealizada para este fim, é necessário muita marretada e gambiarras para que funcione bem, o que perde-se muito em performance.

    Aqui no Brasil usamos muito PHP ou algum framework que usa php como Laravel, CakePHP, slimFramework entre outros, além de Go (o de melhor performance) e Python. O meu preferido com certeza é o bom e velho PHP puro, sem frameworks que instalam milhares de bibliotecas sendo que no final vc acaba usando uns 20% delas ou menos, prefiro usar somente o que realmente vai ser necessário.

    Já para front-end aí sim JS com certeza, pois ele foi idealizado para isso, trabalha muito bem com DOM, JSON, XML, CSS e tudo mais, ou seja, é a praia do JavaScript, atualmente tenho usado o VueJS (meu favorito) acho que é o futuro dos Frameworks Reativos, além do React e AngularJS.

    Mas entendi o intuito da postagem, o Pedro Pinto quis mostrar que é possível fazer um back-end com NodeJS, apesar de na prática termos opções mais viáveis…

    • Leandro says:

      Gustavo pode dar um exemplo concreto dos problemas na utilização do NodeJS para back-end?
      Em que se baseia para para afirmar que o NodeJs é mais lento que o PHP? O NodeJs só utiliza uma thread do processador, a não ser que se façam forks. Um dos principais motivos porque ele é bastante utilizado é que é fácil escalar horizontalmente.
      Note-se que eu não estou a defender o NodeJs. Mas penso que mais do que se dar uma opinião, muitas vezes infundada, deve-se fazer um estudo ou avaliação das caracteristicas de cada linguagem, que secalhar até já a fez.
      O maior problema que eu vejo com o NodeJs é os callbacks onde os iniciantes, e não só, podem rapidamente tornar, do ponto de vista de legibilidade e manutençao, uma determinada função, ou funções, dificeis de perceber. O chamado callback hell.

      • JL says:

        De facto, iniciar no NodeJS sem perceber a utilização dos callback pode ser desmoralizante. Torna a programação e manutenção mais “dolorosa”.
        No entanto, a utilização de ‘Promise ‘ juntamento com funções ‘async’ com ‘try’ e ‘catch’ tornou toda a minha programação muito menos “dolorosa” e, juntamente com a plataforma usada, mais progressiva.

      • Gustavo Antonaci says:

        Olá Leandro, na minha opinião eu deixei claro o porque… JavaScript foi idealizado para uma determinada tarefa “Front-End”, DOM, XML, JSON, validar formulários e por aí vai, não disse que é um problema, é gosto, como você bem disse, só dei minha opinião, não dei detalhes pois não utilizo NodeJS, não conheço os por menores da linguaem.

        Por outro lado o PHP, Go, Python e outros já foram criados pensando nisso, para serem “back-end” para fazer o trabalho por trás, executar consultas, enviar e-mails, gerar arquivos e tantas outras tarefas “back-end”, depois deste tutorial vou procurar saber mais sobre o NodeJS, hoje só o utilizo para instalar dependencias e pacotes no VueJS.

  9. Porfírio says:

    NodeJS não é assim tão descabido para usar em backend. Acreditem que está cada vez mais a ser usado. Empresas grandes como LinkedIn usam no.
    Além disso com o crescimento do chamado Serverless, cada vez mais se está a fazer micro serviços e lambdas em NodeJS
    AWS tem maior suporte para NodeJS ou GO

  10. Pedro Brasil says:

    Excelente artigo. Cumpriu o que propôs. Parabéns, Pedro Pinto. Quanto aos que estão criticando, postem artigos bons como esse. Gosto não se discute e a definição de linguagem ou arquitetura, depende dos objetivos do projeto.

  11. ANDERSON LUIZ SANCHES CARLUCCI PEREIRA says:

    Boa excelente artigo.

  12. Fabiano Bezerra says:

    Possue algum material portugues desse loopback ?

Deixe um comentário

O seu endereço de email não será publicado.

You may use these HTML tags and attributes: <a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

Aviso: Todo e qualquer texto publicado na internet através deste sistema não reflete, necessariamente, a opinião deste site ou do(s) seu(s) autor(es). Os comentários publicados através deste sistema são de exclusiva e integral responsabilidade e autoria dos leitores que dele fizerem uso. A administração deste site reserva-se, desde já, no direito de excluir comentários e textos que julgar ofensivos, difamatórios, caluniosos, preconceituosos ou de alguma forma prejudiciais a terceiros. Textos de caráter promocional ou inseridos no sistema sem a devida identificação do seu autor (nome completo e endereço válido de email) também poderão ser excluídos.