元スレ【PHP】2chat開発スレ【2chを越える】

みんなの評価 :

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ

/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで

501 = :

>>500
お気に入り機能とか使ったことなかった…
タブ170件以上開いて新着チェックしてた

まあそれは置いておいて、
2chmateは使ったことない(IOSだから)よく分からないが、多分専ブラの機能なら大変だろうけどWEBで実装出来ると思う
専ブラ作るのが大変なのはネイティブでも変わらないし

2chは本当WEBページゴミだよな…多分ajaxとかSPAとかが流行ってなかった事に出来たからだと思うけど

502 = :

明日か明後日にはサーバーサイドAPIの実装が終わるので(テストはまだだけど)、クライアントの方はその後に考えます
とりあえずPushしました

504 = :

いつのまにか500行ってた
テストコード１回も書いたことないから何すればいいか分からん。。。

507 = :

>>302だけど、俺もPHP挫折しそうww
コード補完がまともに動かなったり、->の代わりに.をくせでスペルミスしたりで動かなったり効率悪すぎ。
いちいち、メソッド名忘れると、Webで検索してるわ。
開発環境が悪いのかなぁ・・
Windows上のVisual Studio Codeで作って、仮想マシン上のLinuxにデプロイ・実行してるんだけど。

ということで、.NET Core + ASP.NET Coreに移行中。
とりあえず、開発環境と実行環境分けるとあんまいい感じじゃなさそうなので、
Linux上のVisual Studio Codeでやるわ・・

508 = :

VS CodeはJSとかHTMLだと軽くて強力だけどPHPは微妙
VSにPHP Tool(クソ高い)入れるかNetBeansおすすめ(そもそもPHPがゴミだけど)

C#ならVS CodeよりVSの無料版の方が絶対良い

509 = :

>VSにPHP Tool(クソ高い)入れるかNetBeansおすすめ(そもそもPHPがゴミだけど)
勉強目的でいきなりお金払うのわね。NetBeansとかいうのいいんだ。
俺的にはコード補完とかもうちょいまともに効くならPHPという言語でも許容できるけど。

>C#ならVS CodeよりVSの無料版の方が絶対良い
うん。今、それに向けて作業してる。元々、UWPアプリとか作っててVisual Studio 2015使ってるからね。
これ以上、メインマシンをよごしたくなくて、維持でも実行環境(Webサーバー+DBサーバー)は仮想マシン上に構築しようとしてたけど、
Windows上で.NET Core + ASP.NET Coreの開発環境入れてもIISとかインストールされないっぽい(
Kestrelとかいう軽量サーバーがデフォルト？)から、VSにすることにした。
で、データベースだけはLinux上に。

513 = :

全部POSTメソッドなんだ。
つか、ソース見にくすぎだな。

514 = :

つか、これ、コンパイルは通ってるの？？
abstract class HttpApiBase(val tokenFlag:TokenFlag,val strParams:List[String],val intParams:List[String]) extends HttpServlet
Scalaの事よくわからんけど、tokenFlagとかコンストラクタの引数？
継承元のHttpServletってサーブレットコンテナ？がHttpServletのインスタンスを生成して、適切なdoPostとかdoGetとか呼んでくれるんじゃないの？
HttpApiBaseにコンストラクタ引数を宣言してて、だれがこれをセットしてくれるのか？？

515 = :

あ、ごめん。Scalaはなんか違うのか。派生クラスみたら、定数値っぽいのがセットされてるな。

516 = :

>>514
class Hoge(val i:Int)
は
public class Hoge{
　　public final int i;
　　public Hoge(int i){
　　　　this.i=i;
　　}
}
と同じ(実際は内部でgetterが生成されていたりするけど)
かなり短く書ける

518 = :

あっ大事な事忘れていた
web.xmlがない

520 = :

RESTfull API的には
hoge/foo/afef
で、HTTPメソッドGETで取得、POSTで挿入、PUTで更新、PATCHで部分更新、DELETEでリソース削除。

521 = :

>>520
POSTとGETは分かりますが、残りは対応面倒と聞きました
全部POSTに統一が一番シンプルでいいかと思ったので、POSTに統一しています

522 = :

まだ、バグ修正などありますが、APIを頭の中で整理するために仕様書を書きます

523 = :

対応って別に全部に対応する必要はないよ。
例えば、User自体は削除できないんだから、Userに対してDeleteメソッドは定義する必要はないし。
Scalaとか使う道具にはこだわるが、作りだす物にはこだわりがないのかね？
いきなり全部はできんけど。

つか、せめて、取得系はGETでいくべきだ。全部POSTとか、クソAPI呼ばわりされること間違いなし。

RESTful APIに別に無理してしなくてもいいが、
例えばQiitaのAPIはRESTful APIっぽいし。
http://qiita.com/api/v2/docs
http://wp.tech-style.info/archives/683

524 = :

>>523
なるほど
何か難しそうだけどそういう風なのが普通なのか
あとエラーコードの返し方も考えた方がよさそう
全部jsonで返しているし

525 = :

これHTTPの基礎勉強しないと駄目だ

526 = :

RESTにしなくても、RPC的なAPIでもいいと。
http://dev.twitter.com/rest/public
Twitterはそんな感じだけど。パラメータの渡し方は。

527 = :

PATCHとか初めて聞いた

528 = :

いや、エラーは全部JSONでいいよ。他のResponseとかも
JSONで返すんだし統一性がないと俺ならブチ切れる。

529 = :

エラーはHTTPのステータスコードでエラーを示して、
更に詳しい情報やメッセージなどをレスポンスのJSONボディで返すのが
普通かな。大手サービスはだいだいこんな感じ。

530 = :

>>528
エラーの詳細はJSONだろうけど、HTTPステータスがエラーでも200 OK返しているからどうなのかなと思って
例えば、「本文が長すぎます」みたいなのは200 OKでいいの？

531 = :

>>526のTwitterはGET,POSTでパラメータはどっちかというとクエリパラメータで
渡して、RPC的なんだと思う。

532 = :

>>529
大まかなエラー内容はHTTPステータスでいいのか

REST APIで調べたら「セッションなどの状態管理を行わない」って書いてあったけどトークンってこれに含まれる？
何か凄く難しい

533 = :

>>531
twitter参考にしているからこっちがいいのだろうか
何か凄く難しい…
TwitterAPI生では触った事ないから内部でどうなっているか考えた事なかった

534 = :

>>530
それはまずい、それはクライアラント側のエラーだから
ステータスコードは400のBad Requestで、
JSONの方に、本文が長すぎますみたいな感じで。
まぁ、はじめてなんからほどほどでいいけど。

http://tools.ietf.org/html/rfc7231
で、どんなステータスコードあるかサクっと見たほうがいい。
4xx系がクライアント側のエラー
5xx系がサーバー側。例えば、クライアント側のリクエストには問題ないが、
サーバー側で問題発生で処理できないとか。

535 = :

>>534
何か基礎が分かってないみたいだからRESTとRPCを見て、エラーコードも確認してみる
実装は明日にする

536 = :

>REST APIで調べたら「セッションなどの状態管理を行わない」って書いてあったけどトークンってこれに含まれる？
これって認証がらみのトークンだっけ？？
通常は、HTTPのリクエストヘッダにAuthorizationヘッダってあるから
http://tools.ietf.org/html/rfc7235#section-4.2
これで渡してもらうのがふつう。

537 = :

まぁ、ほんとは認証がらみではOAuth2っていうプロトコルあって、
これをどのサービスを使ってるんだけど。まぁ、さすがに今は覚えることありすぎて
やりすぎかな。

QiitaのAPIもTwitterもFacebookもDropboxもOAuth2だし。みんなこれ使ってる。

539 = :

やる事が思っていたより多かった

540 = :

まぁ、俺は何度もHTTPのRFCの仕様を何度もよんだし。
いろいろ大手のAPIを叩いたし、OAuth2のクライアント側も自分で実装したりしたから、
ここらへんは叩き込まれてるけど。あくまでクライアント側だけだから。
>>507で書いたように今はサーバ側を君と一緒に勉強しようとかなと
ここに居座ってるw

541 = :

一度実装したものを作り直すのは大変だから一回表とかにまとめてみる

542 :

>>541
そこだね。見てて思ったんだけど、作り方が水平方向的？なんだよね。
例えば、モデルクラス作るなら、一気に全部モデルクラスを作るみたいな。
これだと、途中で設計まずったときに全部作り直しになるじゃん。
俺なら例えば最初にUserだけのモデル作って、その次は垂直方向にUser用のAPIを作るね。
そうすりゃ、早い段階で問題点に気づけるし、全体像を早い段階で気づける。

543 = :

アジャイル開発って奴か
クラス間の依存とか考えたら結構難しくて…

544 = :

認証後回しにしてメインのスレッドとレスポンスからがいいと思う

545 = :

サブパスワードで安全にしようと考えていたけど、流石に大量のパスワード覚えるのは面倒か
ここ全く考えてなかった

548 = :

HTTPSってサーバーの設定じゃない？
サーブレット側でも対応することあるの？

549 = :

ないと思う。
というよりそういう事いいたかったんじゃなくて、HTTPSはサーバー証明書が
必要になるわけだから、サーバー証明書簡単に取れるのか知らないので
そこらへん気をとめておいてねって言いたかった。

550 = :

証明書無料のあるか探しておく